/Desktop/projects/git` folder and create a `syllabus.md` file there.
+
+We'll be typing our markdown into this file in the Visual Studio Code window. At any time, you can save your file by hitting control + s on Windows or ⌘ + s on macOS. Alternatively, you can click the `File` menu on the top right, then select `Save` from the dropdown menu.
+
+Saving frequently is advised. When we get to the version contol functionality of Git, only changes that are saved will be preserved when a version is created.
+
+---
+# Creating Syllabus Content Using Markdown
+
+We'll be using **Markdown** to write a syllabus, and then using **Git** to track any changes we make to it. Markdown allows us to format textual features like headings, emphasis, links, and lists in a plain text file using a streamlined set of notations that humans can interpret without much training. Markdown files usually have a `.md` extension.
+
+**Markdown** is a markup language for formatting text. Like HTML, you add markers to plain text to style and organize the text of a document.
+
+Whereas you use HTML and CSS with WordPress, you use Markdown to render legible documents on GitHub. Markdown has fewer options for marking text than HTML. It was designed to be easier to write and edit.
+
+For comparison, you learned to create headers in HTML like this:
+
+```html
+My Syllabus Heading
+```
+
+In Markdown, we insert headings with a single hash mark like this:
+
+```markdown
+# My Syllabus Heading
+```
+
+A sub-heading (H2) heading uses two hash marks like this:
+
+```markdown
+## Readings
+```
+
+The lessons of this workshop were originally written in markdown. You can see [here](https://raw.githubusercontent.com/DHRI-Curriculum/git/v2.0/lessons.md) what they look like in their raw, unrendered form.
+
+Compare that with this—the source code for this lesson's web page, written in HTML [here](view-source:http://curriculum.dhinstitutes.org/workshops/git/lessons/).
+
+Markdown is also arguably more sustainable and accessible than formats like `.docx` because of its simplicity and related ability to be read across multiple platforms. Use of Markdown is also supported by document-conversion tools like [Pandoc](https://pandoc.org/) that can change a markdown file to an `.epub` with one command entered into your terminal.
+
+Here are a few more key elements to get you ready to make your own syllabus in Markdown.
+
+To provide emphasis, place asterisks around some text:
+
+```markdown
+*This text will appear italicized.*
+**This text will appear bold.**
+```
+
+For emphasis, you need to mark where it should start and where it should end, so you need astrisks at the beginning and end of whatever text is being emphasized.
+
+To create a bulleted list, put a hyphen at the beginning of each list item:
+
+```markdown
+- Reading one
+- Reading two
+- Reading three
+```
+
+To create a link, put the anchor text (the text you will see) in square brackets and the URL in parentheses, directly following the anchor text in brackets. Don't put a space between them:
+
+```markdown
+I teach at [SMU](https://www.smu.edu/).
+```
+
+Paragraphs of text are denoted by putting a blank line between them:
+
+```markdown
+This is a paragraph in markdown. It's separated from the paragraph below with a blank line. If you know HTML, it's kind of like the tag. That means that there is a little space before and after the paragraph when it is rendered.
+
+This is a second paragraph in markdown, which I'll use to tell you what I like about markdown. I like markdown because it looks pretty good, if minimal, whether you're looking at the rendered or unrendered version. It's like tidy HTML.
+```
+
+## Challenge
+
+Use these five elements—headings, emphasis, lists, links, and paragraphs—to create a syllabus. Have a main heading that gives the course title (one `#`), then subheadings for, at least, course info and readings. Use emphasis (`*`) for book titles and try to get a list in there somewhere.
+
+If you want an a more advanced challenge, you can review some additional markdown elements on [this page](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) and add some extra features like images, blockquotes, or horizontal rules.
+
+## Example
+
+You can look at an example syllabus in raw text form [here](https://raw.githubusercontent.com/SouthernMethodistUniversity/dhri/main/sections/data1.md). When it's rendered by GitHub, it looks like [this](https://github.com/SouthernMethodistUniversity/dhri/blob/main/sections/data1.md). When editing the markdown file in Visual Studio Code, it might look like this:
+
+
+
+## Tips
+
+1. Visual Studio Code also has a preview feature for your markdown. Hit the preview button on the top right while editing your markdown file:
+
+ 
+
+ You'll get two side-by-side panels. Your markdown file will be on the left, and your rendered preview will be on the right:
+
+ 
+
+2. Remember to save your work—regularly!—with control + s on Windows or ⌘ + s on macOS.
+
+---
+
+# Staging and Committing Changes
+
+Git's primary function is version control, or to track a project as it exists at particular points in time. Now that we have a file to track—our `syllabus.md`—let's use Git to save the current state of the repository as it exists now.
+
+## A Metaphor for Adding and Committing
+
+In Git, a _commit_ is a snapshot of a repository that is entered into its permanent history. To commit a change to a repository, we take two steps:
+
+1. Adding files to a "staging area," meaning that we intend to commit them.
+2. Finalizing the commit.
+
+Staging a file or files is you telling Git, "Hey! Pay attention these files and the changes in them".
+
+Making a commit is a lot like taking a photo. First, you have to decide who will be in the photo and arrange your friends or family in front of the camera (the staging process). Once everyone is present and ready, you take the picture, entering that moment into the permanent record (the commit process).
+
+Why do you need both steps? Sometimes when you're working on a project you don't want to pay attention to all the files you changed. Perhaps you fixed a bug in some code, but also did some work on your manuscript document. You may want to only commit the changes you made to the code because you still haven't finished your thoughts on the manuscript. You can stage, or `add`, the code file so Git knows to only commit the changes made to that file. Later, you can stage and then commit the manuscript changes on their own once you've finished your thought.
+
+## Staging Changes with the `add` Command
+
+First, let's see what state Git is currently in. We do that with the `git status` command. It's a good idea to use this command before and after doing anything in a Git repository so you can always be on the same page as the computer.
+
+Make sure you're in your `/home//Desktop/projects/git-practice` directory using the `pwd` command in the terminal. Once you're there, enter `git status` and you should see the following output:
+
+```console
+$ git status
+On branch main
+
+No commits yet
+
+Untracked files:
+ (use "git add ..." to include in what will be committed)
+
+ syllabus.md
+
+nothing added to commit but untracked files present (use "git add" to track)
+```
+
+"Nothing added to commit" means that we have initialized our repository, but haven't made any commits yet. _If you're instead getting a message that begins with the word `fatal` when you use `git status`, you may be in the wrong directory or perhaps you haven't run the `git init` command on your directory yet._
+
+Let's follow the recommendation in the status message above and use the `add` command to stage files, making them ready to be committed.
+
+We will go ahead and add `syllabus.md` by writing the following in the terminal:
+
+```console
+$ git add syllabus.md
+```
+
+You should see no output from the command line, which should be interpreted as a the above command succeeded. It is what we call "succeeding silently." Let's run `git status` again to have a "sanity check"—to make sure that things have changed. You should see output like this:
+
+```
+$ git status
+On branch main
+
+No commits yet
+
+Changes to be committed:
+ (use "git rm --cached ..." to unstage)
+
+ new file: syllabus.md
+```
+
+The `new file: syllabus.md` should be highlighted in green to show that it's ready for commit.
+
+This is Git telling you, "Ok, I see the file(s) you're talking about."
+
+## Committing Changes
+
+Now that our files have been staged, let's commit them, making them part of the permanent record of the repository. In the terminal, type:
+
+```console
+$ git commit -m "Initial commit of syllabus file"
+```
+
+The `-m` flag provides that the message following the flag (in quotation marks) along with the commit. The message will tell others—or remind a future version of yourself—what the commit was all about. Try not to type `git commit` without the `-m` flag—there's a note about this below.
+
+After running the command, you should see output like this:
+
+```
+[main (root-commit) 8bb8306] Initial commit of syllabus file
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 syllabus.md
+```
+
+This means you have successfully made your first commit in the repository—congratulations! There are a few things going on in this message. The relevant information for you for now is the second line, which tells you that one file was changed, and there were no insertions or deletions. You have a fresh new file!
+
+Let's check the state of our repository after the commit by running `git status`:
+
+```
+$ git status
+On branch main
+nothing to commit, working tree clean
+```
+
+This means that everything in the repository is successfully committed and up-to-date. If you edit your syllabus file or create a new file in the repository, the message you get with `git status` will instead list files that have uncommitted changes.
+
+Let's run one other command to see the effect our commit has had. Enter this command:
+
+```console
+$ git log
+```
+
+You should see output similar to this:
+
+```
+commit 8bb8306c1392eed52d4407eb16867a49b49a46ac (HEAD -> main)
+Author: Your Name
+Date: Sun May 20 16:03:39 2018 -0400
+
+ Initial commit of syllabus file
+```
+
+This is the log of commits, comprising a history of your repository. There's only one commit here now, though. If you don't see a prompt (the `$`) after running `git log`, you may need to press the q key (just the q key by itself) to return to the command line.
+
+## Why Do We Need to Use the `-m` Flag?
+
+The `-m` flag is useful for human purposes and technical purposes. For human purposes, the `-m` flag helps you keep track of the changes you're making. Version control is most useful when you can confidently return to a specific version. It can also help you be more structured in your approach to making changes—your notes to self are limited, so to make them clear, you might make commits after specific tasks are completed. If you update readings for the first week of classes or if you add another reading, you will want to make a commit. This can also make it easier to reverse a specific change in the future.
+
+Also, if you type `git commit` by itself, git will open the command line's default text editor to allow you to enter the commit message in a file-like environment. It looks something like this:
+
+
+
+This unfamiliar screen is the default text editor, `vi`, and it requires some knowledge to use. We don't teach it as part of our sessions, but if you find yourself stuck in this screen, you can try this trick to leave that environment and return to your usual command prompt. Type `:q` and then press enter. You should be back to the command line with a message saying:
+
+```console
+Aborting commit due to empty commit message.
+```
+
+If you make a mistake where you include an opening quotation mark but forget a closing one, you might accidentally end up inside a "quote prompt." You will know you're there when your command prompt changes to `quote>`. If this happens, you can just keep writing as much of your commit message as you want, and then end it with the same quotation mark that you opened the commit message with.
+
+Another option is to press control + c on your keyboard, which will exit the quote prompt and cancel any commits you were trying to perform.
+
+## Pro-tip for the Command Line: How to exit unknown screens
+
+If you're ever stuck or "trapped" on the command line, try running through these common exit commands to return to the prompt:
+
+- control + c
+- control + d
+- `q` followed by enter
+- `:q` followed by enter
+
+control + c attempts to abort the current task and restore user control. control + d escapes the current shell environment—if you use it at the normal `$` prompt, it will end the current command line session. `q` is often used as a command (followed by enter) to escape from specific programs like `less`. `:q` is the command used in `vi` that changes the mode of interaction (`:`), allowing you to enter the `q`, a one-letter command to quit, which must be followed by enter. Thus, it's a command specific to `vi`.
+
+ [More about Tracking changes](https://swcarpentry.github.io/git-novice/04-changes.html)
+
+
+---
+
+# Pushing to GitHub
+
+Now, let's connect the directory you made to GitHub. GitHub is a service that allows us to host files, collaborate, and find the work of others. Once our syllabus is on GitHub, it will be publicly visible.
+
+Go to GitHub in your browser and click the plus sign in the upper right hand corner.
+
+
+
+After clicking the plus button, select `New repository` from the dropdown menu.
+
+
+
+After clicking `New repository`, you'll have to enter some information, including a name and description for your repository.
+
+
+
+- Choose a name, such as `git-practice`.
+- Enter a description, such as `Test syllabus for learning Git and GitHub`.
+- Keep the `Public — Anyone can see this repository` selector checked.
+- Do *not* select `Initialize this repository with a README` since you will be importing an existing repository from your computer.
+- Click `Create repository`.
+
+You should end up inside your newly created git-practice repo. It will look like a set of instructions that you might want to use to connect your GitHub repository to a local repository.
+
+The instructions we want consist of three lines underneath the heading `...or push an existing repository from the command line`. The arrow in this screenshot points to where these directions are on the page:
+
+
+
+Copy out the first command and paste it in your terminal. It should look something like this:
+
+```console
+git remote add origin https://github.com//.git
+```
+
+You'll need the command copied from your new repo, since it will contain the correct URL.
+
+Next, paste the second command. It will look exactly like this:
+
+```console
+git branch -M main
+```
+
+Finally, paste the third command. It will look exactly like this:
+
+```console
+git push -u origin main
+```
+
+If you have not used git before, you will need to authenticate with GitHub, and a window will pop up asking you to sign in. Click `Sign in with your browser`:
+
+
+
+Your browser should open a window asking you to "Authorize Git Credential Manager." Click the green `Authorize GitCredentialManager` button:
+
+
+
+You should see a message that authentication succeeded. If so, you may now close the browser window and return to the command line, where you should see output like this:
+
+```console
+Total 4 (delta 3), reused 0 (delta 0)
+remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
+To github.com:/git.git
+ 916998f..9779fa7 master -> master
+```
+
+If you see output like this, go back to your new repository page in the browser and click the `Refresh` button. You should see your `syllabus.md` file on GitHub! Your git credentials are also now stored locally, so you should not need to authorize the credential manager again from that computer.
+
+---
+
+# Cloning and Forking
+
+GitHub was built for sharing and collaborating on projects. A key advantage of the platform is that you can find lots of bits of software that do many different things—such as code for plugins for WordPress or Leaflet. Increasingly, you might find syllabi or open writing projects. If a project is public, you can save a copy of it to your local machine, work on it, save your amendations and share it on your own GitHub account. Like we've already mentioned, GitHub usefully helps track attribution along the way.
+
+Cloning and forking are the basic functions of this capability. Each are first explained below, and followed by an example and activity to further explain.
+
+## Cloning
+
+**Cloning** a repository means making a copy of a repository on GitHub, to download and work on locally—on your local machine. By entering the following code into your terminal, you can clone any public directory on GitHub:
+
+```console
+$ git clone
+```
+
+When you clone a repository from GitHub, the folder that shows up on your local machine comes built-in with a few things. First, Git is already present, so you don't need to initialize the folder. Also, the connection between your local copy and the online repository is already made, so `git push origin main` will work (no `-u` flag needed).
+
+For practice, let's clone the repository for this workshop about Git and GitHub, which [lives on GitHub](https://southernmethodistuniversity.github.io/git/).
+
+First, let's navigate back to your Desktop folder.
+
+```console
+$ cd ~/Desktop
+```
+
+Remember that the `~` refers to your home directory. Now let's find the URL we need to clone the lesson.
+
+First, follow [this link to the main page of this lesson on Git and GitHub](https://github.com/SouthernMethodistUniversity/git).
+
+On the main page, there should be a green `Code` button on the right side:
+
+
+
+Click the green button and you will see a box with highlighted text under a heading that says `Clone with HTTPS`. If you instead see `Cloning with SSH`, click the small link that says `Use HTTPS`.
+
+Now copy out the text in the box:
+
+
+
+Now that you have the text copied, go back to your terminal. Remember, you should be on the `Desktop`. (Hint: Use `pwd` to find out what your current working directory is.)
+
+Once you are in the `Desktop`, type:
+
+```console
+$ git clone
+```
+
+If the command is successful, the full Git and GitHub workshop's text will be replicated on your local machine. To navigate into the folder, its name is `git` and you can use the `cd` command to access it:
+
+```console
+$ cd git
+```
+
+Use the `ls` command to take a look at the various files in the lesson folder.
+
+Cloning can be especially useful when you're joining a group project that is hosted on GitHub, and you want your changes to eventually be pushed and shared with that same repository.
+
+But maybe that is not possible or ideal. Maybe you don't want to contribute your changes to someone else's repository. Maybe you want to make a derivative of their folder for yourself, on your GitHub account, and make changes there.
+
+Forking is the step you could take to do this.
+
+## Forking
+
+_Forking_ a repository means making a copy of someone else's repository on GitHub, and saving it to your account on GitHub. This function happens within GitHub, and has nothing to do with what is happening on your local machine. Note that _forking_ will not automatically make the repository appear as a folder on your computer; that's the role of _cloning_.
+
+In order to "fork" the `git` repository into your own GitHub account, follow these steps.
+
+First, go to [the repository for this workshop](https://github.com/SouthernMethodistUniversity/git) on GitHub. Note the `Fork` button in the upper right hand corner. By clicking that button, you can copy, or fork, this repository to your account.
+
+
+
+Doing so would also adjust the attribution information in the upper left hand corner. Your username would replace `SouthernMethodistUniversity`, showing that you are looking at a copy of the repository on your account now. Additionally, it will reference the origin account, in this case, `SouthernMethodistUniversity` below after `forked from`, since this was the origin point of _your_ fork.
+
+
+
+Your local machine would come into play when you want to _clone_ that repository so you can work on it locally. This also means that when you push those changes to GitHub, you would be pushing them to a forked repository associated with your own account.
+
+You might use this method if you were going to teach your own Git & GitHub workshop. You could use our repository as a base for getting started, and add more examples or change some language, clarify something further, or create a connection to another workshop you are giving, etc. This allows us to continue to use the workshop as we have it as well. Also, maybe at a later time, we want to merge some of your changes with ours. We can do that too by revisiting your version history.
+
+## Challenge
+
+1. Fork and clone [the repository for this workshop](https://github.com/SouthernMethodistUniversity/git). Note not only _what_ you are doing, but also _where_ you are working when completing these two different tasks.
+2. Make changes to the files on your local machine. Remember to save them!
+3. Use the 3-step process of stage, commit and push to return the amended files to the repository on GitHub.
+
+## Solution
+
+Rather than write out the solution here, I want to encourage you to go back through the lessons as needed.
+
+You'll know you've completed step one when the project folder (called `git`) shows up on your local machine.
+
+After you've made and saved the changes, you'll know you've completed step three when your changes appear in the project folder on _your_ GitHub account.
+
+*Additional content*
+
+# Collaborating
+[How can I use version control to collaborate with other people?](https://swcarpentry.github.io/git-novice/08-collab.html)
+A BASIC COLLABORATIVE WORKFLOW
+* In practice, it is good to be sure that you have an updated version of the repository you are collaborating on, so you should git pull before making our changes. The basic collaborative workflow would be:
+- update your local repo with git pull origin main,
+- make your changes and stage them with git add,
+- commit your changes with git commit -m, and
+- upload the changes to GitHub with git push origin main
+It is better to make many commits with smaller changes rather than of one commit with massive changes: small commits are easier to read and review.
+
+# Conflicts
+[What do I do when my changes conflict with someone else’s?](https://swcarpentry.github.io/git-novice/09-conflict.html)
+
+**Discussion Questions**
+- What does your current version control workflow look like and what are the challenges it poses; or how could it be improved?
+- How can git support the work you are already doing?
+- What additional opportunities does git and/or GitHub and/or Markdown create for your teaching, research or other scholarly work?
+- What are the potential benefits and pitfalls of working in the open on the web via a platform like GitHub?
+
+## Reference sheets for Quick Reference
+**Cheatsheets For Git**
+- [Git Cheatsheets for Quick Reference](https://swcarpentry.github.io/git-novice/reference.html#top)
+- Printable Git cheatsheets in several languages are [available here](https://github.github.com/training-kit/) ([English version](https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf)). More material is available from the [GitHub training website](https://try.github.io/).
+- An [interactive one-page visualization](https://ndpsoftware.com/git-cheatsheet.html)
+ about the relationships between workspace, staging area, local repository, upstream repository, and the commands associated with each (with explanations).
+- Both resources are also available in other languages (e.g. Spanish, French, and more).
+- "[Happy Git and GitHub for the useR](https://happygitwithr.com)" is an accessible, free online book by Jenny Bryan on how to setup and use Git and GitHub with specific references on the integration of Git with RStudio and working with Git in R.
+- [Open Scientific Code using Git and GitHub](https://open-source-for-researchers.github.io/open-source-workshop/) - A collection of explanations and short practical exercises to help researchers learn more about version control and open source software.
+
+**Cheatsheets For Markdown**
+- [Markdown Cheat Sheet:](https://www.markdownguide.org/cheat-sheet/) provides a quick overview of all the Markdown syntax elements.
+- [The Markdown Guide](https://www.markdownguide.org) contains reference guides for [basic syntax](https://www.markdownguide.org/basic-syntax) and [extended syntax](https://www.markdownguide.org/extended-syntax).
+
+## Glossary
+- [Short Software Carpentry Glossary](https://swcarpentry.github.io/git-novice/reference.html#glossary)
+- [Full GitGlossary](https://git-scm.com/docs/gitglossary)
+
+### Full Software Carpentry Workshop
+-[Full Workshop Content](https://swcarpentry.github.io/git-novice/)
+-[Discussion](https://carpentries-incubator.github.io/git-novice-branch-pr/discuss/)
\ No newline at end of file
diff --git a/_site/sections/introgithub.md b/_site/sections/introgithub.md
new file mode 100644
index 0000000..bb973c2
--- /dev/null
+++ b/_site/sections/introgithub.md
@@ -0,0 +1,660 @@
+# How to use GitHub
+**Hands on workshop, online**
+- In this 60 minute workshop, participants will be introduced to GitHub and how to access online repositories.
+
+**Github** (required)
+- **[Create a GitHub account](https://github.com/join) (required)**
+- You need to have a GitHub account for the purposes of this workshop. It is free to sign up via this link.
+- For SMU affiliates (students, faculty,staff): If you already have an account, you *do not need to create another account.* In the settings section of your personal account, you can add additional emails, such as your SMU email.
+
+
+***Authenticating to Remote Git Repositories***
+"Git provides multiple protocols for authenticating to and interacting with remote Git repositories.
+
+There are three main approaches you can take:
+- Using a personal authentication token or password
+- Using an SSH key
+- Using your GitHub password with 2-factor authentication"
+- [See these directions from Berkeley Statistics](https://statistics.berkeley.edu/computing/faqs/git-auth)
+ - For additional directions, [see Github's Authentication documentation](https://docs.github.com/authentication)
+
+
+- [Get started using GitHub in less than an hour.](https://github.com/skills/introduction-to-github)
+- DS1300 [https://southernmethodistuniversity.github.io/ds_1300/book/03_github_and_initial_setup.html]
+
+
+# Getting Started with Git and GitHub (Workshop)
+
+**Git** is software used for version control—that is, tracking the state of files and changes you make to them over time. Git can be enabled in a folder, and then used to save the state of the contents in that folder at different points in the future, as designated by you. In the language of Git, a folder is called a _repository_. In the context of this workshop, it refers to a folder that is being tracked by Git. Using Git, you can view a log of the changes you've made to the files in a repository and compare changes over time. We will explore these features in the current workshop. You can also revert back to previous versions, and create "branches" of a project to explore different futures. These are advanced features, which we will provide resources for you to explore later. Git is also useful for collaboration, as a repository can be shared across computers, and its contents can be asynchronously developed and eventually merged with the main project.
+
+**GitHub** is an online platform for hosting Git repositories. It functions for some, predominantly programmers, as a social network for sharing and collaborating on code-based projects. Users can share their own projects, as well as search for others, which they can then often work on and contribute to. Digital Humanists, librarians, and other academics are also finding ways Git and GitHub are useful in writing projects and teaching. GitHub also serves as a web-hosting platform, allowing users to create websites from their repositories.
+
+
+## Highlighting Distinctions
+
+As we move forward it's important to make sure we're firm on the distinctions between the three different tools outlined above.
+
+**Git** is a software that you use on your laptop, or your local computer/machine. The repository with your project's files is stored on your hard drive. You also edit the text files on your local machine using a plain text editor, which is another software on your local computer like Visual Studio Code.
+
+**GitHub** is a cloud-based platform that you access through your internet browser. Even though you physically are still in the same place, working on your laptop, you are no longer working on your local machine, you are on the Internet. This is a fundamentally different location than when you're working with your Git repository and editing and creating files in your plain text editor. With GitHub, you are uploading your repository—as described above—from your local machine to this platform on the Internet to be shared more broadly. You can also create private repositories if you want to use GitHub to backup a project.
+
+
+# Why use it? What You Can Do with Git and GitHub ?
+
+* Link to presentation slides
+
+
+## How We Use GitHub
+
+### Collaborative Writing
+
+Git is also used in writing projects! _Version control_ makes tracking changes trackable, especially when there are multiple authors working asynchronously. It can be an alternative to using track changes in Microsoft Word, or comments and edits in a Google Doc.
+
+### Versions Across Time (Version control)
+
+How did you initially come by the syllabus you use for your class(es), and did you develop it over time? Many professors borrow and adapt from each other, and most of us probably update our syllabi each semester, even if only a little bit.
+
+Through this process, many of us end up with a set of files that looks something like this:
+
+
+While I probably can tell which version is the "final" one, I can not see what was changed along the way or how the different versions vary from each other.
+
+With Git, you would save these multiple versions over time as one file, and each version you save includes a note about what has changed so you can easily revert back to an older version if needed.
+
+By looking at the file list, you also can not tell who the syllabus originally came from, or if there were contributions from many individuals. Git and GitHub can help make attribution clear, and maintain it over time as the syllabus travels between hands.
+
+**Syllabi examples**
+* Increasingly we see that faculty are sharing their syllabi on GitHub (example: [DLCL 204: Digital Humanities Across Borders](https://github.com/quinnanya/dlcl204)). Some are even using GitPages that apply a user-friendly interface to their repository to make it easier to access and navigate for their students (example: [Digital History](https://digitalhistory.github.io/)).
+
+With version control:
+- Nothing that is committed to version control is ever lost, unless you work really, really hard at it. Since all old versions of
+ files are saved, it's always possible to go back in time to see exactly who wrote what on a particular day, or what version of a
+ program was used to generate a particular set of results.
+ - Teams are not the only ones to benefit from version control: lone researchers can benefit immensely. Keeping a record of what was
+changed, when, and why is extremely useful for all researchers if they ever need to come back to the project later on (e.g., a year later,
+when memory has faded).
+- As we have this record of who made what changes when, we know who to ask if we have questions later on, and, if needed, revert to a previous version, much like the "undo" feature in an editor.
+- When several people collaborate in the same project, it's possible to accidentally overlook or overwrite someone's changes. The version control system automatically notifies users whenever there's a conflict between one person's work and another's.
+- Version control is the lab notebook of the digital world: it's what professionals use to keep track of what they've done and to
+collaborate with other people. Every large software development project relies on it, and most programmers use it for their small jobs
+as well. And it isn't just for software: books, papers, small data sets, and anything that changes over time or needs
+to be shared can and should be stored in a version control system.
+
+ [Click here for extended explanation of: What is version control](https://swcarpentry.github.io/git-novice/01-basics.html)
+
+### Sharing and Attribution
+
+As you can see [we use GitHub to host workshop curricula.](https://github.com/SouthernMethodistUniversity?q=git&type=all&language=&sort=) Hosting sessions on GitHub allows you (and anyone else interested in these topics!) to follow our repositories, and create your own version of the workshop based on our materials. This fosters open scholarship and knowledge sharing. It also facilitates attribution and citation by clearly tracking which content was created by whom, when it was added, and which projects or materials are derived from others.[As you can see in our acknowledgements](https://github.com/SouthernMethodistUniversity/git#acknowledgements)
+- You can [add a citation file as well](https://swcarpentry.github.io/git-novice/12-citation.html)
+
+---
+* Github & Digital Humanities: A [study of how Digital Humanists use GitHub](https://digitalscholarship.files.wordpress.com/2016/07/spirosmithdh2016githubpresentationfinal.pdf), conducted by Lisa Spiro and Sean Morey Smith, found that a wide range of users, including professors, research staff, graduate students, IT staff, and librarians commonly used the site in their DH work. They used GitHub for a diverse range of activities, such as:
+
+- Developing software
+- Sharing data sets
+- Creating websites
+- Writing articles and books
+- Collating online resources
+- Keeping research notes
+- Hosting syllabi and course materials
+
+
+* Github & Open Science
+- When version control is diligently, it acts as a shareable electronic lab notebook for computational work
+- It helps make code citable
+- [Open scientific work](https://swcarpentry.github.io/git-novice/10-open.html)
+
+---
+
+
+# SET UP: Setting Up Git
+
+Through this section, you'll be checking your installation and configuring Git with your own name and information.
+
+## Check Your Installation
+
+First, let's make sure [Git](https://git-scm.com/downloads) has been successfully installed. In your terminal, type the following command:
+
+```console
+$ git --version
+```
+
+If you see a version number, you're all set. If not, follow the installation instructions [here](https://gc-dri.github.io/Dhrift-GC/workshops/git/?page=5) or [here](https://swcarpentry.github.io/git-novice/index.html#installing-git).
+
+## Configuring Git on Your Computer
+
+Our first step in working with Git is letting the software know who we are so it can track our work and attribute our contributions. This information is useful because it connects identifying information with the changes you make in your repository.
+
+Type the following _two commands_ into your command line, replacing the "John Doe" and "johndoe@example.com" with your name and email (use quotations where you see them). These do not necessarily need to be the name and email you used to sign up for GitHub. Remember, these are different spaces and different softwares.
+
+```console
+$ git config --global user.name "John Doe"
+$ git config --global user.email johndoe@example.com
+```
+
+To check your set-up, type the following command into your terminal:
+
+```console
+$ git config --list
+```
+
+You should get something that looks like this except with whatever information you entered previously:
+
+```
+user.name=Superstar Git User
+user.email=gitsuperstar@gmail.com
+```
+
+ [More about setting up git](https://swcarpentry.github.io/git-novice/02-setup.html)
+
+---
+
+# Creating a Syllabus File
+
+The next step is to _initialize_ the project folder that we want Git to track. Even though we configured Git for our computer, Git doesn't start tracking every single file on our computer. That would turn into a headache quickly. We only want Git to track changes for files within specific folders/projects.
+
+When we initialize a folder, we are telling Git to pay attention to it. This only needs to happen once because what is actually happening through this process is Git is adding a hidden subfolder within your folder that houses the internal data structure required for version control. After initialization, Git is ready to track the files within the folder. The folder is now considered a Git _repository_.
+
+First, use `cd`, navigate to the `git-practice` folder (inside `projects`). From your home directory, you can do all of them in one command by typing the following into your terminal:
+
+```console
+$ cd Desktop/projects/git-practice
+```
+
+Next we're going to _initialize_ our repository using the `git init` command, which should generate the following output:
+
+```console
+$ git init
+Initialized empty Git repository in /home//projects/git/.git/
+```
+
+Now Git is tracking our directory. However, it has not done any versioning yet. This is because 1) we haven't told Git to take a snapshot yet, and 2) there are no files in the folder to take a snapshot of. For now, Git knows this folder exists and is prepared to take a snapshot of the files when you tell it to.
+
+Before version control is useful, we'll have to create a text file for Git to track. For this session, the file we will track will be a course syllabus—we'll create that next.
+
+[More about creating a repository](https://swcarpentry.github.io/git-novice/03-create.html)
+
+## Creating a plain text file
+
+To quickly create a plain text file in your practice folder, enter the following command
+
+```console
+$ echo "hello" > hello.txt
+```
+## Creating a Syllabus file (Creating a Markdown file using an IDE)
+
+To create a plain text file, we're going to switch to our text editor, Visual Studio Code, to create and edit a file named `syllabus.md` and save it to our `git-practice` folder. The `.md` extension indicates that it is a Markdown file, which is a special file format we will dive into in the next section.
+
+If you have not installed Visual Studio Code, review [the installation instructions here](https://github.com/DHRI-Curriculum/install/blob/v2.0/guides/visual-studio-code.md).
+
+In terminal, check to make sure you are in your `git-practice` folder. (_Hint_: use `pwd` to see what directory you are currently in.)
+
+Next, open the `syllabus.md` file in Visual Studio Code using:
+
+```console
+$ code syllabus.md
+```
+
+**Note** code is the command used for Visual Studio code. If this does not work, or you would like to set a different text editor, you can do so using the correct [configuration command, as listed on this page](https://swcarpentry.github.io/git-novice/02-setup.html#line-endings) for the text editor.
+
+```console
+$ git config --global core.editor "Add specific command for text editor"
+```
+
+
+You should see a window appear that looks similar to this:
+
+
+
+If Visual Studio Code does not open when you use the `code` command in your terminal, open it using the Start Menu on Windows or Spotlight Search on macOS as you would any other software. Then click `File > Open File` and use the dialog to navigate to the `/Users//Desktop/projects/git` folder and create a `syllabus.md` file there.
+
+We'll be typing our markdown into this file in the Visual Studio Code window. At any time, you can save your file by hitting control + s on Windows or ⌘ + s on macOS. Alternatively, you can click the `File` menu on the top right, then select `Save` from the dropdown menu.
+
+Saving frequently is advised. When we get to the version contol functionality of Git, only changes that are saved will be preserved when a version is created.
+
+---
+# Creating Syllabus Content Using Markdown
+
+We'll be using **Markdown** to write a syllabus, and then using **Git** to track any changes we make to it. Markdown allows us to format textual features like headings, emphasis, links, and lists in a plain text file using a streamlined set of notations that humans can interpret without much training. Markdown files usually have a `.md` extension.
+
+**Markdown** is a markup language for formatting text. Like HTML, you add markers to plain text to style and organize the text of a document.
+
+Whereas you use HTML and CSS with WordPress, you use Markdown to render legible documents on GitHub. Markdown has fewer options for marking text than HTML. It was designed to be easier to write and edit.
+
+For comparison, you learned to create headers in HTML like this:
+
+```html
+My Syllabus Heading
+```
+
+In Markdown, we insert headings with a single hash mark like this:
+
+```markdown
+# My Syllabus Heading
+```
+
+A sub-heading (H2) heading uses two hash marks like this:
+
+```markdown
+## Readings
+```
+
+The lessons of this workshop were originally written in markdown. You can see [here](https://raw.githubusercontent.com/DHRI-Curriculum/git/v2.0/lessons.md) what they look like in their raw, unrendered form.
+
+Compare that with this—the source code for this lesson's web page, written in HTML [here](view-source:http://curriculum.dhinstitutes.org/workshops/git/lessons/).
+
+Markdown is also arguably more sustainable and accessible than formats like `.docx` because of its simplicity and related ability to be read across multiple platforms. Use of Markdown is also supported by document-conversion tools like [Pandoc](https://pandoc.org/) that can change a markdown file to an `.epub` with one command entered into your terminal.
+
+Here are a few more key elements to get you ready to make your own syllabus in Markdown.
+
+To provide emphasis, place asterisks around some text:
+
+```markdown
+*This text will appear italicized.*
+**This text will appear bold.**
+```
+
+For emphasis, you need to mark where it should start and where it should end, so you need astrisks at the beginning and end of whatever text is being emphasized.
+
+To create a bulleted list, put a hyphen at the beginning of each list item:
+
+```markdown
+- Reading one
+- Reading two
+- Reading three
+```
+
+To create a link, put the anchor text (the text you will see) in square brackets and the URL in parentheses, directly following the anchor text in brackets. Don't put a space between them:
+
+```markdown
+I teach at [SMU](https://www.smu.edu/).
+```
+
+Paragraphs of text are denoted by putting a blank line between them:
+
+```markdown
+This is a paragraph in markdown. It's separated from the paragraph below with a blank line. If you know HTML, it's kind of like the tag. That means that there is a little space before and after the paragraph when it is rendered.
+
+This is a second paragraph in markdown, which I'll use to tell you what I like about markdown. I like markdown because it looks pretty good, if minimal, whether you're looking at the rendered or unrendered version. It's like tidy HTML.
+```
+
+## Challenge
+
+Use these five elements—headings, emphasis, lists, links, and paragraphs—to create a syllabus. Have a main heading that gives the course title (one `#`), then subheadings for, at least, course info and readings. Use emphasis (`*`) for book titles and try to get a list in there somewhere.
+
+If you want an a more advanced challenge, you can review some additional markdown elements on [this page](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) and add some extra features like images, blockquotes, or horizontal rules.
+
+## Example
+
+You can look at an example syllabus in raw text form [here](https://raw.githubusercontent.com/SouthernMethodistUniversity/dhri/main/sections/data1.md). When it's rendered by GitHub, it looks like [this](https://github.com/SouthernMethodistUniversity/dhri/blob/main/sections/data1.md). When editing the markdown file in Visual Studio Code, it might look like this:
+
+
+
+## Tips
+
+1. Visual Studio Code also has a preview feature for your markdown. Hit the preview button on the top right while editing your markdown file:
+
+ 
+
+ You'll get two side-by-side panels. Your markdown file will be on the left, and your rendered preview will be on the right:
+
+ 
+
+2. Remember to save your work—regularly!—with control + s on Windows or ⌘ + s on macOS.
+
+---
+
+# Staging and Committing Changes
+
+Git's primary function is version control, or to track a project as it exists at particular points in time. Now that we have a file to track—our `syllabus.md`—let's use Git to save the current state of the repository as it exists now.
+
+## A Metaphor for Adding and Committing
+
+In Git, a _commit_ is a snapshot of a repository that is entered into its permanent history. To commit a change to a repository, we take two steps:
+
+1. Adding files to a "staging area," meaning that we intend to commit them.
+2. Finalizing the commit.
+
+Staging a file or files is you telling Git, "Hey! Pay attention these files and the changes in them".
+
+Making a commit is a lot like taking a photo. First, you have to decide who will be in the photo and arrange your friends or family in front of the camera (the staging process). Once everyone is present and ready, you take the picture, entering that moment into the permanent record (the commit process).
+
+Why do you need both steps? Sometimes when you're working on a project you don't want to pay attention to all the files you changed. Perhaps you fixed a bug in some code, but also did some work on your manuscript document. You may want to only commit the changes you made to the code because you still haven't finished your thoughts on the manuscript. You can stage, or `add`, the code file so Git knows to only commit the changes made to that file. Later, you can stage and then commit the manuscript changes on their own once you've finished your thought.
+
+## Staging Changes with the `add` Command
+
+First, let's see what state Git is currently in. We do that with the `git status` command. It's a good idea to use this command before and after doing anything in a Git repository so you can always be on the same page as the computer.
+
+Make sure you're in your `/home//Desktop/projects/git-practice` directory using the `pwd` command in the terminal. Once you're there, enter `git status` and you should see the following output:
+
+```console
+$ git status
+On branch main
+
+No commits yet
+
+Untracked files:
+ (use "git add ..." to include in what will be committed)
+
+ syllabus.md
+
+nothing added to commit but untracked files present (use "git add" to track)
+```
+
+"Nothing added to commit" means that we have initialized our repository, but haven't made any commits yet. _If you're instead getting a message that begins with the word `fatal` when you use `git status`, you may be in the wrong directory or perhaps you haven't run the `git init` command on your directory yet._
+
+Let's follow the recommendation in the status message above and use the `add` command to stage files, making them ready to be committed.
+
+We will go ahead and add `syllabus.md` by writing the following in the terminal:
+
+```console
+$ git add syllabus.md
+```
+
+You should see no output from the command line, which should be interpreted as a the above command succeeded. It is what we call "succeeding silently." Let's run `git status` again to have a "sanity check"—to make sure that things have changed. You should see output like this:
+
+```
+$ git status
+On branch main
+
+No commits yet
+
+Changes to be committed:
+ (use "git rm --cached ..." to unstage)
+
+ new file: syllabus.md
+```
+
+The `new file: syllabus.md` should be highlighted in green to show that it's ready for commit.
+
+This is Git telling you, "Ok, I see the file(s) you're talking about."
+
+## Committing Changes
+
+Now that our files have been staged, let's commit them, making them part of the permanent record of the repository. In the terminal, type:
+
+```console
+$ git commit -m "Initial commit of syllabus file"
+```
+
+The `-m` flag provides that the message following the flag (in quotation marks) along with the commit. The message will tell others—or remind a future version of yourself—what the commit was all about. Try not to type `git commit` without the `-m` flag—there's a note about this below.
+
+After running the command, you should see output like this:
+
+```
+[main (root-commit) 8bb8306] Initial commit of syllabus file
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 syllabus.md
+```
+
+This means you have successfully made your first commit in the repository—congratulations! There are a few things going on in this message. The relevant information for you for now is the second line, which tells you that one file was changed, and there were no insertions or deletions. You have a fresh new file!
+
+Let's check the state of our repository after the commit by running `git status`:
+
+```
+$ git status
+On branch main
+nothing to commit, working tree clean
+```
+
+This means that everything in the repository is successfully committed and up-to-date. If you edit your syllabus file or create a new file in the repository, the message you get with `git status` will instead list files that have uncommitted changes.
+
+Let's run one other command to see the effect our commit has had. Enter this command:
+
+```console
+$ git log
+```
+
+You should see output similar to this:
+
+```
+commit 8bb8306c1392eed52d4407eb16867a49b49a46ac (HEAD -> main)
+Author: Your Name
+Date: Sun May 20 16:03:39 2018 -0400
+
+ Initial commit of syllabus file
+```
+
+This is the log of commits, comprising a history of your repository. There's only one commit here now, though. If you don't see a prompt (the `$`) after running `git log`, you may need to press the q key (just the q key by itself) to return to the command line.
+
+## Why Do We Need to Use the `-m` Flag?
+
+The `-m` flag is useful for human purposes and technical purposes. For human purposes, the `-m` flag helps you keep track of the changes you're making. Version control is most useful when you can confidently return to a specific version. It can also help you be more structured in your approach to making changes—your notes to self are limited, so to make them clear, you might make commits after specific tasks are completed. If you update readings for the first week of classes or if you add another reading, you will want to make a commit. This can also make it easier to reverse a specific change in the future.
+
+Also, if you type `git commit` by itself, git will open the command line's default text editor to allow you to enter the commit message in a file-like environment. It looks something like this:
+
+
+
+This unfamiliar screen is the default text editor, `vi`, and it requires some knowledge to use. We don't teach it as part of our sessions, but if you find yourself stuck in this screen, you can try this trick to leave that environment and return to your usual command prompt. Type `:q` and then press enter. You should be back to the command line with a message saying:
+
+```console
+Aborting commit due to empty commit message.
+```
+
+If you make a mistake where you include an opening quotation mark but forget a closing one, you might accidentally end up inside a "quote prompt." You will know you're there when your command prompt changes to `quote>`. If this happens, you can just keep writing as much of your commit message as you want, and then end it with the same quotation mark that you opened the commit message with.
+
+Another option is to press control + c on your keyboard, which will exit the quote prompt and cancel any commits you were trying to perform.
+
+## Pro-tip for the Command Line: How to exit unknown screens
+
+If you're ever stuck or "trapped" on the command line, try running through these common exit commands to return to the prompt:
+
+- control + c
+- control + d
+- `q` followed by enter
+- `:q` followed by enter
+
+control + c attempts to abort the current task and restore user control. control + d escapes the current shell environment—if you use it at the normal `$` prompt, it will end the current command line session. `q` is often used as a command (followed by enter) to escape from specific programs like `less`. `:q` is the command used in `vi` that changes the mode of interaction (`:`), allowing you to enter the `q`, a one-letter command to quit, which must be followed by enter. Thus, it's a command specific to `vi`.
+
+ [More about Tracking changes](https://swcarpentry.github.io/git-novice/04-changes.html)
+
+
+---
+
+# Pushing to GitHub
+
+Now, let's connect the directory you made to GitHub. GitHub is a service that allows us to host files, collaborate, and find the work of others. Once our syllabus is on GitHub, it will be publicly visible.
+
+Go to GitHub in your browser and click the plus sign in the upper right hand corner.
+
+
+
+After clicking the plus button, select `New repository` from the dropdown menu.
+
+
+
+After clicking `New repository`, you'll have to enter some information, including a name and description for your repository.
+
+
+
+- Choose a name, such as `git-practice`.
+- Enter a description, such as `Test syllabus for learning Git and GitHub`.
+- Keep the `Public — Anyone can see this repository` selector checked.
+- Do *not* select `Initialize this repository with a README` since you will be importing an existing repository from your computer.
+- Click `Create repository`.
+
+You should end up inside your newly created git-practice repo. It will look like a set of instructions that you might want to use to connect your GitHub repository to a local repository.
+
+The instructions we want consist of three lines underneath the heading `...or push an existing repository from the command line`. The arrow in this screenshot points to where these directions are on the page:
+
+
+
+Copy out the first command and paste it in your terminal. It should look something like this:
+
+```console
+git remote add origin https://github.com//.git
+```
+
+You'll need the command copied from your new repo, since it will contain the correct URL.
+
+Next, paste the second command. It will look exactly like this:
+
+```console
+git branch -M main
+```
+
+Finally, paste the third command. It will look exactly like this:
+
+```console
+git push -u origin main
+```
+
+If you have not used git before, you will need to authenticate with GitHub, and a window will pop up asking you to sign in. Click `Sign in with your browser`:
+
+
+
+Your browser should open a window asking you to "Authorize Git Credential Manager." Click the green `Authorize GitCredentialManager` button:
+
+
+
+You should see a message that authentication succeeded. If so, you may now close the browser window and return to the command line, where you should see output like this:
+
+```console
+Total 4 (delta 3), reused 0 (delta 0)
+remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
+To github.com:/git.git
+ 916998f..9779fa7 master -> master
+```
+
+If you see output like this, go back to your new repository page in the browser and click the `Refresh` button. You should see your `syllabus.md` file on GitHub! Your git credentials are also now stored locally, so you should not need to authorize the credential manager again from that computer.
+
+---
+
+# Cloning and Forking
+
+GitHub was built for sharing and collaborating on projects. A key advantage of the platform is that you can find lots of bits of software that do many different things—such as code for plugins for WordPress or Leaflet. Increasingly, you might find syllabi or open writing projects. If a project is public, you can save a copy of it to your local machine, work on it, save your amendations and share it on your own GitHub account. Like we've already mentioned, GitHub usefully helps track attribution along the way.
+
+Cloning and forking are the basic functions of this capability. Each are first explained below, and followed by an example and activity to further explain.
+
+## Cloning
+
+**Cloning** a repository means making a copy of a repository on GitHub, to download and work on locally—on your local machine. By entering the following code into your terminal, you can clone any public directory on GitHub:
+
+```console
+$ git clone
+```
+
+When you clone a repository from GitHub, the folder that shows up on your local machine comes built-in with a few things. First, Git is already present, so you don't need to initialize the folder. Also, the connection between your local copy and the online repository is already made, so `git push origin main` will work (no `-u` flag needed).
+
+For practice, let's clone the repository for this workshop about Git and GitHub, which [lives on GitHub](https://southernmethodistuniversity.github.io/git/).
+
+First, let's navigate back to your Desktop folder.
+
+```console
+$ cd ~/Desktop
+```
+
+Remember that the `~` refers to your home directory. Now let's find the URL we need to clone the lesson.
+
+First, follow [this link to the main page of this lesson on Git and GitHub](https://github.com/SouthernMethodistUniversity/git).
+
+On the main page, there should be a green `Code` button on the right side:
+
+
+
+Click the green button and you will see a box with highlighted text under a heading that says `Clone with HTTPS`. If you instead see `Cloning with SSH`, click the small link that says `Use HTTPS`.
+
+Now copy out the text in the box:
+
+
+
+Now that you have the text copied, go back to your terminal. Remember, you should be on the `Desktop`. (Hint: Use `pwd` to find out what your current working directory is.)
+
+Once you are in the `Desktop`, type:
+
+```console
+$ git clone
+```
+
+If the command is successful, the full Git and GitHub workshop's text will be replicated on your local machine. To navigate into the folder, its name is `git` and you can use the `cd` command to access it:
+
+```console
+$ cd git
+```
+
+Use the `ls` command to take a look at the various files in the lesson folder.
+
+Cloning can be especially useful when you're joining a group project that is hosted on GitHub, and you want your changes to eventually be pushed and shared with that same repository.
+
+But maybe that is not possible or ideal. Maybe you don't want to contribute your changes to someone else's repository. Maybe you want to make a derivative of their folder for yourself, on your GitHub account, and make changes there.
+
+Forking is the step you could take to do this.
+
+## Forking
+
+_Forking_ a repository means making a copy of someone else's repository on GitHub, and saving it to your account on GitHub. This function happens within GitHub, and has nothing to do with what is happening on your local machine. Note that _forking_ will not automatically make the repository appear as a folder on your computer; that's the role of _cloning_.
+
+In order to "fork" the `git` repository into your own GitHub account, follow these steps.
+
+First, go to [the repository for this workshop](https://github.com/SouthernMethodistUniversity/git) on GitHub. Note the `Fork` button in the upper right hand corner. By clicking that button, you can copy, or fork, this repository to your account.
+
+
+
+Doing so would also adjust the attribution information in the upper left hand corner. Your username would replace `SouthernMethodistUniversity`, showing that you are looking at a copy of the repository on your account now. Additionally, it will reference the origin account, in this case, `SouthernMethodistUniversity` below after `forked from`, since this was the origin point of _your_ fork.
+
+
+
+Your local machine would come into play when you want to _clone_ that repository so you can work on it locally. This also means that when you push those changes to GitHub, you would be pushing them to a forked repository associated with your own account.
+
+You might use this method if you were going to teach your own Git & GitHub workshop. You could use our repository as a base for getting started, and add more examples or change some language, clarify something further, or create a connection to another workshop you are giving, etc. This allows us to continue to use the workshop as we have it as well. Also, maybe at a later time, we want to merge some of your changes with ours. We can do that too by revisiting your version history.
+
+## Challenge
+
+1. Fork and clone [the repository for this workshop](https://github.com/SouthernMethodistUniversity/git). Note not only _what_ you are doing, but also _where_ you are working when completing these two different tasks.
+2. Make changes to the files on your local machine. Remember to save them!
+3. Use the 3-step process of stage, commit and push to return the amended files to the repository on GitHub.
+
+## Solution
+
+Rather than write out the solution here, I want to encourage you to go back through the lessons as needed.
+
+You'll know you've completed step one when the project folder (called `git`) shows up on your local machine.
+
+After you've made and saved the changes, you'll know you've completed step three when your changes appear in the project folder on _your_ GitHub account.
+
+*Additional content*
+
+# Collaborating
+[How can I use version control to collaborate with other people?](https://swcarpentry.github.io/git-novice/08-collab.html)
+A BASIC COLLABORATIVE WORKFLOW
+* In practice, it is good to be sure that you have an updated version of the repository you are collaborating on, so you should git pull before making our changes. The basic collaborative workflow would be:
+- update your local repo with git pull origin main,
+- make your changes and stage them with git add,
+- commit your changes with git commit -m, and
+- upload the changes to GitHub with git push origin main
+It is better to make many commits with smaller changes rather than of one commit with massive changes: small commits are easier to read and review.
+
+# Conflicts
+[What do I do when my changes conflict with someone else’s?](https://swcarpentry.github.io/git-novice/09-conflict.html)
+
+
+
+
+**Discussion Questions**
+- What does your current version control workflow look like and what are the challenges it poses; or how could it be improved?
+- How can git support the work you are already doing?
+- What additional opportunities does git and/or GitHub and/or Markdown create for your teaching, research or other scholarly work?
+- What are the potential benefits and pitfalls of working in the open on the web via a platform like GitHub?
+
+## Reference sheets for Quick Reference
+**Cheatsheets For Git**
+- [Git Cheatsheets for Quick Reference](https://swcarpentry.github.io/git-novice/reference.html#top)
+- Printable Git cheatsheets in several languages are [available here](https://github.github.com/training-kit/) ([English version](https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf)). More material is available from the [GitHub training website](https://try.github.io/).
+- An [interactive one-page visualisation](https://ndpsoftware.com/git-cheatsheet.html)
+ about the relationships between workspace, staging area, local repository, upstream repository, and the commands associated with each (with explanations).
+- Both resources are also available in other languages (e.g. Spanish, French, and more).
+- "[Happy Git and GitHub for the useR](https://happygitwithr.com)" is an accessible, free online book by Jenny Bryan on how to setup and use Git and GitHub with specific references on the integration of Git with RStudio and working with Git in R.
+- [Open Scientific Code using Git and GitHub](https://open-source-for-researchers.github.io/open-source-workshop/) - A collection of explanations and short practical exercises to help researchers learn more about version control and open source software.
+
+**Cheatsheets For Markdown**
+- [Markdown Cheat Sheet:](https://www.markdownguide.org/cheat-sheet/) provides a quick overview of all the Markdown syntax elements.
+- [The Markdown Guide](https://www.markdownguide.org) contains reference guides for [basic syntax](https://www.markdownguide.org/basic-syntax) and [extended syntax](https://www.markdownguide.org/extended-syntax).
+
+
+### Full Software Carpentry Workshop
+-[Full Workshop Content](https://swcarpentry.github.io/git-novice/)
+-[Discussion](https://carpentries-incubator.github.io/git-novice-branch-pr/discuss/)
+
+## Glossary
+- [Short Software Carpentry Glossary](https://swcarpentry.github.io/git-novice/reference.html#glossary)
+- [Full GitGlossary](https://git-scm.com/docs/gitglossary)
diff --git a/_site/sections/logo.png b/_site/sections/logo.png
new file mode 100644
index 0000000..b1d8d64
Binary files /dev/null and b/_site/sections/logo.png differ
diff --git a/_site/sections/quickstart.md b/_site/sections/quickstart.md
new file mode 100644
index 0000000..58157d5
--- /dev/null
+++ b/_site/sections/quickstart.md
@@ -0,0 +1,26 @@
+# Quickstart
+## Explore Github on your own
+**If you already having coding skills, are comfortable with using the command line (see [Playing with text on the command line](https://github.com/veltman/learninglunches/tree/master/commandline)) and you are just looking for quickstart to GitHub, you can use the following links:**
+
+### Sign up for a Github account
+- Sign up for a Github account [by clicking here](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account)
+- Create a 'personal account, which serves as your identity on GitHub.com.
+- [Select free and follow the prompts.](https://github.com/pricing)
+
+
+# Quickstart lessons
+- [Github Quickstart: Follow this Hello World exercise to get started with GitHub.](https://docs.github.com/en/get-started/quickstart/hello-world)
+- [Software Carpentry: Version Control with Git](https://swcarpentry.github.io/git-novice/)
+
+
+# LinkedIn Learning: Github
+- [LinkedIn Learning is available to all *active* faculty, staff, and students.](https://www.smu.edu/OIT/Services/LinkedIn)
+- You can [log into LinkedIn Learning](https://www.smu.edu/OIT/Services/linkedin) and search for the following courses.
+ - Git Essential Training:The Basics [LinkedIn Learning](https://www.linkedin.com/learning/git-essential-training-the-basics/)
+ - GitHub Essential Training [LinkedIn Learning](https://www.linkedin.com/learning/github-essential-training/version-control-and-collaboration-with-github?u=2139050)
+ - Learning GitHub [LinkedIn Learning](https://www.linkedin.com/learning/learning-github)
+
+
+*Note:* SMU participates in the [GitHub Campus Program.](https://www.smu.edu/OIT/Services/GitHub) The GitHub Campus Program is available to all *active* faculty, staff, and students.
+[Sign into SMU's Github Enterprise account](http://github.smu.edu/) and upload content using your web browser.
+
diff --git a/_site/sections/whatgitandgithub.md b/_site/sections/whatgitandgithub.md
new file mode 100644
index 0000000..37de1f4
--- /dev/null
+++ b/_site/sections/whatgitandgithub.md
@@ -0,0 +1,107 @@
+# What are Git & GitHub
+- In this 30 minute workshop participants will be introduced to what Git and Github are.
+- This workshop is discussion based only.
+
+## Workshop objectives
+- In this beginner-level workshop, participants will get an introduction to the general principles of Git and Github. No prior experience with Git or Github is required.
+
+### Why use it? What You Can Do with Git and GitHub ?
+
+* Link to presentation slides
+
+# What is Git? (*software*)
+
+**Git** is *software* that you use on your laptop, or your local computer/machine. The software is used for *version control*—that is, tracking the state of files and changes you make to them over time. It is a Version Control System (VCS).
+- Git can be enabled in a folder, and then used to save the state of the contents in that folder at different points in the future, as designated by you.
+- In the language of Git, a folder (that is being tracked by Git) is called a *repository*.
+- Using Git, you can view a *log* of the changes you've made to the files in a repository and compare changes over time.
+- You can also revert back to previous versions, and create "branches" of a project to explore different futures.
+- Git is useful for collaboration, as a repository can be shared across computers, and its contents can be asynchronously developed and eventually merged with the main project.
+Version Control system (VCS)/ distributed version control system (DVCS)
+
+# What is GitHub? (*web based*)
+
+**GitHub** is an *online platform* for *hosting Git repositories.* It is a cloud-based platform that you access through your internet browser.
+- It functions for some, predominantly programmers, as a social network for sharing and collaborating on code-based projects.
+- Users can share their own projects, as well as search for others, which they can then often work on and contribute to.
+- Digital Humanists, librarians, and other academics are also finding ways Git and GitHub are useful in writing projects and teaching.
+- GitHub also serves as a web-hosting platform, allowing users to create websites from their repositories.
+- With GitHub, you are uploading your repository—as described above—from your local machine to this platform on the Internet to be shared more broadly.
+
+
+## How We Use GitHub
+
+### Collaboration
+
+**Collaborative Writing**
+
+Git is also used in writing projects! _Version control_ makes tracking changes trackable, especially when there are multiple authors working asynchronously. It can be an alternative to using track changes in Microsoft Word, or comments and edits in a Google Doc.
+
+ [Click here for information on branches](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches)
+
+
+### Instruction
+
+**Syllabi sharing**
+
+Increasingly we see that faculty are sharing their syllabi on GitHub (example: [DLCL 204: Digital Humanities Across Borders](https://github.com/quinnanya/dlcl204)).
+
+**Class Websites**
+
+
+Some instructors are even using GitPages that apply a user-friendly interface to their repository to make it easier to access and navigate for their students (examples: [DS 1300: A Practical Introduction to Data Science](https://southernmethodistuniversity.github.io/ds_1300/book/00_introduction.html) & [Digital History](https://digitalhistory.github.io/)).
+
+For courses in disciplines such as Data Sciences or Computer Science, instructors will put assignments, code or notebooks in the class repository and may even require their students to submit assignments using GitHub.
+
+
+### Version control
+
+**Versions Across Time**
+
+How did you initially come by the syllabus you use for your class(es), and did you develop it over time? Many professors borrow and adapt from each other, and most of us probably update our syllabi each semester, even if only a little bit.
+
+Through this process, many of us end up with a set of files that looks something like this:
+
+
+While I probably can tell which version is the "final" one, I can not see what was changed along the way or how the different versions vary from each other.
+
+With Git, you would save these multiple versions over time as one file, and each version you save includes a note about what has changed so you can easily revert back to an older version if needed.
+
+By looking at the file list, you also can not tell who the syllabus originally came from, or if there were contributions from many individuals. Git and GitHub can help make attribution clear, and maintain it over time as the syllabus travels between hands.
+
+*With version control:*
+- Nothing that is committed to version control is ever lost, unless you work really, really hard at it. Since all old versions of files are saved, it's always possible to go back in time to see exactly who wrote what on a particular day, or what version of a program was used to generate a particular set of results.
+ - Teams are not the only ones to benefit from version control: lone researchers can benefit immensely. Keeping a record of what was changed, when, and why is extremely useful for all researchers if they ever need to come back to the project later on (e.g., a year later, when memory has faded).
+- As we have this record of who made what changes when, we know who to ask if we have questions later on, and, if needed, revert to a previous version, much like the "undo" feature in an editor.
+- When several people collaborate in the same project, it's possible to accidentally overlook or overwrite someone's changes. The version control system automatically notifies users whenever there's a conflict between one person's work and another's.
+- Version control is the lab notebook of the digital world: it's what professionals use to keep track of what they've done and to collaborate with other people. Every large software development project relies on it, and most programmers use it for their small jobs as well. And it isn't just for software: books, papers, small data sets, and anything that changes over time or needs to be shared can and should be stored in a version control system.
+
+ [Click here for extended explanation of: What is version control](https://swcarpentry.github.io/git-novice/01-basics.html)
+
+
+### Sharing and Attribution
+
+As you can see [we use GitHub to host workshop curricula.](https://github.com/SouthernMethodistUniversity?q=git&type=all&language=&sort=) Hosting sessions on GitHub allows you (and anyone else interested in these topics!) to follow our repositories, and create your own version of the workshop based on our materials. This fosters open scholarship and knowledge sharing. It also facilitates attribution and citation by clearly tracking which content was created by whom, when it was added, and which projects or materials are derived from others.[As you can see in our acknowledgements](https://github.com/SouthernMethodistUniversity/git#acknowledgements)
+- You can [add a citation file as well](https://swcarpentry.github.io/git-novice/12-citation.html)
+
+---
+*Github & Digital Humanities*
+- A [study of how Digital Humanists use GitHub](https://digitalscholarship.files.wordpress.com/2016/07/spirosmithdh2016githubpresentationfinal.pdf), conducted by Lisa Spiro and Sean Morey Smith, found that a wide range of users, including professors, research staff, graduate students, IT staff, and librarians commonly used the site in their DH work. They used GitHub for a diverse range of activities, such as:
+- Developing software
+- Sharing data sets
+- Creating websites
+- Writing articles and books
+- Collating online resources
+- Keeping research notes
+- Hosting syllabi and course materials
+
+*Github & Open Science*
+- When version control is diligently, it acts as a shareable electronic lab notebook for computational work
+- It helps make code citable
+- [Open scientific work](https://swcarpentry.github.io/git-novice/10-open.html)
+
+### Glossary for Git
+- [Full Git Glossary](https://git-scm.com/docs/gitglossary)
+
+### Glossary for GitHub
+- [Github Glossary:](https://docs.github.com/en/get-started/quickstart/github-glossary) This glossary introduces common Git and GitHub terminology.
diff --git a/_site/sections/whycoding.md b/_site/sections/whycoding.md
new file mode 100644
index 0000000..5bf9c63
--- /dev/null
+++ b/_site/sections/whycoding.md
@@ -0,0 +1,299 @@
+# Why Learn Coding (Optional)
+* This section is to give context to
+
+# Computing
+Understanding computing: This section is to familiarize you wth important foundational concepts and to give you a framework for understanding the types of computational methods you can use on a projects, including: minimal computing, tool choice or coding. Finally, this session aims to give you language to conceptualize what is possible and to communicate more effectively with partners.
+
+* Understanding the affordances and limitations of a computational approach for your project will help you better imagine, plan manage your project. Even if you are not directly involved in the coding aspect, this will give you the tools to better collaborate with those who will.
+
+# Computers & The Internet
+## What is a computer?
+* How do you make the computer do stuff? What is a GUI?
+* Refer back to the optional viewing from the introduction:
+* The following links will introduce terms such as input, output, storage, CPU, hardware, software, bits, circuits, and the operating system, as well as wired, cables, WiFi, packets, DNS, IP addresses, packets and routing, HTTP and HTML, encryption, public keys, and how search works.
+ * [Code.org. Introducing How Computers Work.YouTube](https://www.youtube.com/watch?v=OAx_6-wdslM&list=PLzdnOPI1iJNcsRwJhvksEo1tJqjIqWbN) [Watch all 6 short videos.]
+ * [What Is the Internet? YouTube](https://www.youtube.com/watch?v=Dxcc6ycZ73M&list=PLzdnOPI1iJNfMRZm5DDxco3UdsFegvuB7) [Watch all 8 short videos.]
+ * [Same series at Kahn Academy](https://www.khanacademy.org/computing/code-org/computers-and-the-internet#how-computers-work)
+
+## What computational skills are necessary for your goals?
+* Keep in mind: What coding language do I need to learn *or* do I need to learn to code is *not the right question,* the question is how much do I need to learn for my specific goal?
+* You may have multifaceted goals, some are learning related and some are productivity related.
+* They may not be mutually exclusive, but you will likely still need to make choices based on your circumstances.
+
+# Computing Environment
+* "The computing environment involves the collection of computer machinery, data storage devices, work stations, software applications, and networks that support the processing and exchange of electronic information..." -[Computing Environment](https://www.sciencedirect.com/topics/computer-science/computing-environment)
+
+*What does this all mean?*
+
+## What is your environment?
+* How can you interact with your environment (local, virtual, cloud)?
+* There are different affordances and limitation in each environment, you will make different choices depending on the needs of you project or the needs of your classroom.
+* Below we go further into depth about the difference and then the reasons we made the choice we did for the Python session.
+
+## Local environments
+- Your laptop or desktop or tablet, etc. is your local environment.
+* The applications on your device can access the resources in your machine. Each local environment becomes different with use.
+* The [kernel](https://en.wikipedia.org/wiki/Kernel_(operating_system)) connects the application software to the hardware of a computer.
+
+[](https://en.wikipedia.org/wiki/File:Kernel_Layout.svg)
+
+* Local installations give you more control, and more power, but the pedagogical tradeoff is that it is more difficult to manage and configure during class. Installation is dependent on type of device.
+
+* The process of installing and learning how to work on your computer encourages more active troubleshooting as well, which is a useful long-term skill.
+
+
+## Virtual environments
+
+A virtual environment is a digital instance of a local computing environment that can perform almost all the same functions as that local machine, ["including running applications and operating systems. Virtual machines run on a physical machines"](https://cloud.google.com/learn/what-is-a-virtual-machine)... using specialized software or internet browsers.
+
+
+## The "Cloud"
+- ["Cloud computing](https://en.wikipedia.org/wiki/Cloud_computing) is the on-demand availability of computer system resources, especially data storage (cloud storage) and computing power, without direct active management by the user.Cloud computing is the on-demand availability of computer system resources, especially data storage (cloud storage) and computing power, without direct active management by the user."
+
+* Cloud based systems may be expensive, it may be resources intensive, so you may choose the path of [Minimal Computing](https://go-dh.github.io/mincomp/about/): "We use “minimal computing” to refer to computing done under some set of significant constraints of hardware, software, education, network capacity, power, or other factors. Minimal computing includes both the maintenance, refurbishing, and use of machines to do DH work out of necessity along with the use of new streamlined computing hardware like the Raspberry Pi or the Arduino micro controller to do DH work by choice. This dichotomy of choice vs. necessity focuses attention on computing that is decidedly not high-performance."
+* Using the resource tha matches your needs can help you minimize costs and environmental impact.
+
+# How do you interact with your computer?
+* Most of us are used to a graphical user interface [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface) but the command line allows you more control.
+
+# Command Line
+
+* What is the command line and why is it like this?
+
+The command line is a text-based way of interacting with your computer. Working in command line helps you make a mental model of how you environment is layed out. This environment is the result of a series of choices, made by humans.
+
+You may hear it called different names, such as the terminal, the shell, or bash. In practice, you can use these terms interchangeably. If you're curious, though, you can read more about them [here.](https://askubuntu.com/questions/506510/what-is-the-difference-between-terminal-console-shell-and-command-line) The shell we use (whether terminal, shell, or bash) is a program that accepts commands as text input and converts commands into appropriate operating system functions.
+
+And yes, "the command line" is also laden with masculine and military metaphors, which is reflective of the history of computing and programming.
+
+* As Wendy Hui Kyong Chun discusses in ["On Software, or the Persistence of Visual Knowledge," (2004)](https://direct.mit.edu/grey/article/doi/10.1162/1526381043320741/10837/On-Software-or-the-Persistence-of-Visual-Knowledge) almost all computers (as in human comput-ers) in the US during World War II were young women. Human computers received commands from analysts — predominantly men with the military — that they then had to interpret and act upon the machine. As Chun argues, "computation depends on 'yes, sir' in response to short declarative sentences and imperatives that are in essence commands ... The command line is a mere operating system (OS) simulation" (page 34). The command line (of computers today) receives these commands as text that is typed in.
+
+
+
+
+## Why is the command line useful?
+
+Initially, for some of us, the command line can feel a bit unfamiliar. Why step away from a GUI point-and-click workflow? By using the command line, we move into an environment where we have more minute control over each task we'd like the computer to perform. Instead of ordering your food in a restaurant, you're stepping into the kitchen. It's more work, [but there are also more possibilities."](https://www.freecodecamp.org/news/command-line-for-beginners/#whyshouldievencareaboutusingtheterminal)
+
+The command line allows you to...
+
+* Easily automate tasks such as creating, copying, and converting files.
+* Set up your programming environment.
+* Run programs you create.
+* Access the (many) programs and utilities that do not have graphical equivalents.
+* Control other computers remotely.
+
+In addition to being a useful tool in itself, the command line gives you access to a second set of programs and utilities and is a complement to learning programming.
+ * Wring a script or program (programming!) allows you to automate a series of repetitive tasks.
+
+What if all these cool possibilities seem a bit abstract to you right now? That's all right! On a very basic level, most uses of the command line are about **showing information** that the computer has, or **modifying or making** things (files, programs, etc.) on the computer.
+
+## Introduction to the command line
+
+By this point in our academic careers, most of us have figured out some ways we like to interact with computers. Whether that involves avoiding them as much as possible or constantly testing new software, we likely have some ideas about how we feel comfortable getting things done. How would you show a person who had never seen a computer, say [Kimmy Schmidt](https://youtu.be/LIdFa1qLgNQ) or [Brendan Fraser in *Blast from the Past*](https://youtu.be/Xq29uTtKW4M), how to *do* something on your computer?
+
+Many of us would explain what a screen and a cursor are, and then show how to point and click on icons. This approach relies on athe graphical user interface, or GUI (pronounced "gooey!").
+
+Another way to make your computer do things: through the command line. Instead of pointing and clicking, we'll be typing in either Git bash (Windows) or terminal (OSX) to tell the computer directly what task we'd like it to perform.
+
+* Here is an external [command line tutorial](https://ryanstutorials.net/linuxtutorial/) if you wish to learn more.
+
+
+# Coding
+ Why teach coding?
+“...any instructor—-in the humanities or otherwise-—must first ask herself what she hopes her students will accomplish by learning to code. *Is it an understanding of how to think algorithmically, so as to better comprehend how certain tasks can be abstracted into a series of steps? Is it a familiarity with the basic components of programming languages, so as to be able to understand how code is structured and produced? Is it the knowledge of a specialized programming language, one with specific applications in a particular field? Or is it the more experiential knowledge of what it feels like to move from defining functions and assigning variables to running executable code?"*
+[Digital Pedagogy in the Humanities: Concepts, Models, and Experiments: Code by Lauren Klein](https://digitalpedagogy.mla.hcommons.org/keywords/code/)
+
+* Do you need to learn code?
+* You don't need to be become fluent if it's not the focus of your interest, but it is helpful to have reading fluency, like any other language that is an important part of your research. Also, like any other language, use will help you retain and gain knowledge.
+
+## Learning some coding will help you see what is technically feasible
+* "I started to notice that the way people talk about technology is out of sync with what digital technology actually can do. Ultimately, everything we do with computers comes down to math, and there are fundamental limits to what we can (and should) do with it." [Hello Reader](https://direct.mit.edu/books/book/3671/chapter-abstract/122354/Hello-Reader)
+
+## What is coding? Is it the same as programming?
+"Put simply, programming is giving a set of instructions to a computer to execute. ...*While sometimes used interchangeably, programming and coding actually have different definitions."*
+* "*Programming* is the mental process of thinking up instructions to give to a machine (like a computer)."
+ * We have also referred to this as **computational thinking.**
+ * "If you’ve ever cooked using a recipe before, you can think of yourself as the computer and the recipe’s author as a programmer. The recipe author provides you with a set of instructions which you read and then follow. The more complex the instructions, the more complex the result!"
+ * [What is Programming?](https://www.codecademy.com/articles/what-is-programming)
+* "*Coding* is the process of transforming those ideas into a written language that a computer can understand."
+ * Coding would be taking that recipe and laying out step by step what needs to be done,with no assumption of specific knowledge. Without coding, the program (recipe) cannot be run by the computer.
+ * We will be learning to code in Python for this Institute.
+
+# Hello World
+**To better understand how computers make sense of the world, please read:** [Chapter 2 Hello World](https://ebookcentral-proquest-com.proxy.libraries.smu.edu/lib/southernmethodist/reader.action?docID=5355856&ppg=23)
+ * From [Broussard, Meredith. Artificial Unintelligence: How Computers Misunderstand the World. Cambridge, Massachusetts: The MIT Press, 2018.](https://merbroussard.github.io/book/)
+* She talks about the three ways to do something (write Hello World): asking a person to do it, using a tool (Word or some other word processor) to do it, and using coding to do it.
+ * For your "hello world" which is your project, which of the three choices makes the most sense for you?
+ * What are the affordances and limitations of doing computational analysis for your humanities questions?
+* How do you interpret the statements that "data is socially constructed" and "Ultimately, data always comes down to people counting things"?
+* Computers are literal: Can you describe a time in which a computer. tool or program behaved in way that was confusing to you and after reading this article, do you have explanation as to why?
+
+* What can computers actually do?
+ * "The gap between what we imagine and what computers can actually do is really vast... Often, we talk about computers as being able to do anything, and that’s just rhetoric because ultimately they’re machines, and what they do is they compute, they calculate, and so anything you can turn into math, a computer can do." [Interview with Meredith Broussard](https://www.theverge.com/2018/5/23/17384324/meredith-broussard-artifical-unintelligence-technology-criticism-technochauvinism)
+
+* Can you think of something that a human is better at doing then a computer?
+
+
+
+
+# Should you learn coding or just use a tool?
+* The answer to this depends on your immediate and long term goals.
+* What are you trying to do? What are the affordances or limitations of each approach?
+* Learning programming is like learning [carpentry](https://software-carpentry.org/about/) as it is a whole suite of skills.
+ * However, if you just need a specific piece of furniture, then learning carpentry (coding) may be overkill.
+ * Instead, you may just buy something that already exists (get an already existing program/tool like Omeka or Arc-GIS). If your need to common, there may already be a tool.
+ * For example, many people want a tool to do word precessing, there are many various tools that help wth that task.
+* If you sill require a custom solution you can hire a carpenter (hire a developer/programer) to either modify an already existing tool to fit your specfic parameters or make something custom to fit your needs.
+
+## Some questions to consider:
+* Do you see yourself using this skill in multiple contexts?
+* Do you have the time and interest to invest the time to learn the required skills?
+* Have you done a search (or conducted an environmental scan) on your topic and goals? *Imagine the tool that you wished existed and search to see it exists.*
+ * Contact your librarians for help with this.
+
+ # Contexts
+Why am I learning this? Why does it matter? How will it help my project? Learning new digital skills is an investment of your valuable time, so it is reasonable to want to know—essentially—what will I get out of taking this workshop? The materials below help situate the skills you are about to learn within a larger context of how they are used, by whom, and to what ends.
+
+## Ethical Considerations
+- Digital tools and the skills required to use them are part of our culture and, therefore, never neutral. Digital humanists and social scientists consider the ethical challenges and responsibilities of the tools and methods that they use. The following materials are designed to introduce you to issues you may want to consider as you learn this new skill and decide how to integrate it into your own research and teaching.
+- Within the nebulous open-source ecosystem, GitHub is an important place for storing and finding code. What if your open source code was used by an entity or for a purpose that did not agree with your ethics? For example, the platform received backlash from employees of GitHub and users of the platform when it was revealed that they held a contract with ICE. In this case, neither group wanted their code shared and used by ICE in detaining and deporting immigrants. [Read more here.](https://www.theatlantic.com/technology/archive/2020/01/ice-contract-github-sparks-developer-protests/604339/)
+
+
+
+
+-----
+### Attribution
+
+Session Leaders: [Rafia Mirza](http://guides.smu.edu/prf.php?account_id=142826/) Written by Rafia Mirza.
+
+Our curriculum is based on the [Digital Research Institute (DRI) Curriculum](http://purl.org/dc/terms/) by [Graduate Center Digital Initiatives.](https://gcdi.commons.gc.cuny.edu/) It is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](http://creativecommons.org/licenses/by-sa/4.0/). When sharing this material or derivative works, preserve this paragraph, changing only the title of the derivative work, or provide comparable attribution.
+
+[](http://creativecommons.org/licenses/by-sa/4.0/)
+
+
+
.
+
+
+
+