will's comments

CONTRIBUTING.md

@@ -51,19 +51,20 @@ The following is a set of guidelines for contributing to the website repository,
       - [**2.6.b What to do if you have to stop working mid issue:**](#26b-what-to-do-if-you-have-to-stop-working-mid-issue)
     - [**2.7 Working on an issue**](#27-working-on-an-issue)
       - [**2.7.a Working on an issue (1): Verify current branch is `gh-pages`**](#27a-working-on-an-issue-1-verify-current-branch-is-gh-pages)
-      - [**2.7.b Working on an issue (2): Creating and testing your issue branch**](#27b-working-on-an-issue-2-creating-and-testing-your-issue-branch)
+      - [**2.7.b Working on an issue (2): Creating your issue branch**](#27b-working-on-an-issue-2-creating-your-issue-branch)
+      - [**2.7.c Working on an issue (3): Testing your changes**](#27c-testing-your-changes)
         - [**i. A few notes regarding Docker:**](#i-a-few-notes-regarding-docker)
-      - [**2.7.c Working on an issue(3): Prepare your changes to push to your repository**](#27c-working-on-an-issue3-prepare-your-changes-to-push-to-your-repository)
+      - [**2.7.d Working on an issue(4): Prepare your changes to push to your repository**](#27d-working-on-an-issue-4-prepare-your-changes-to-push-to-your-repository)
         - [**i. Prepare repo changes (1): Use the `git add` command to stage your changes.**](#i-prepare-repo-changes-1-use-the-git-add-command-to-stage-your-changes)
         - [**ii. Prepare repos changes (2): Use the `git status` command to see what files are staged.**](#ii-prepare-repos-changes-2-use-the-git-status-command-to-see-what-files-are-staged)
         - [**iii. Prepare repos changes (3): Use the `git reset HEAD` command to remove a staged file.**](#iii-prepare-repos-changes-3-use-the-git-reset-head-command-to-remove-a-staged-file)
         - [**iv. Prepare repos changes (4): Use the `git commit` command**](#iv-prepare-repos-changes-4-use-the-git-commit-command)
-      - [**2.7.d Working on an issue (4): Pulling from upstream before you push**](#27d-working-on-an-issue-4-pulling-from-upstream-before-you-push)
+      - [**2.7.e Working on an issue (5): Pulling from upstream before you push**](#27e-working-on-an-issue-5-pulling-from-upstream-before-you-push)
         - [**i. If there are no changes in the upstream repository**](#i-if-there-are-no-changes-in-the-upstream-repository)
         - [**ii. If there are conflicting changes in the upstream repository**](#ii-if-there-are-conflicting-changes-in-the-upstream-repository)
-      - [**2.7.e Working on an issue (5): Incorporating changes from upstream**](#27e-working-on-an-issue-5-incorporating-changes-from-upstream)
+      - [**2.7.f Working on an issue (6): Incorporating changes from upstream**](#27f-working-on-an-issue-6-incorporating-changes-from-upstream)
         - [**i. Incorporating changes into your topic branch**](#i-incorporating-changes-into-your-topic-branch)
-      - [**2.7.f Working on an issue (6): Handling SSH authorization errors**](#27f-working-on-an-issue-6-handling-ssh-authorization-errors)
+      - [**2.7.g Working on an issue (7): Handling SSH authorization errors**](#27g-working-on-an-issue-7-handling-ssh-authorization-errors)
         - [**i. Setting up SSH Keys for Mac**](#i-setting-up-ssh-keys-for-mac)
         - [**ii. Setting up SSH Keys for Windows**](#ii-setting-up-ssh-keys-for-windows)
   - [**Part 3: Pull Requests**](#part-3-pull-requests)
@@ -520,7 +521,7 @@ git pull upstream gh-pages
 
 <sub>[Back to Table of Contents](#table-of-contents)</sub>
 
-#### **2.7.b Working on an issue (2): Creating and testing your issue branch**
+#### **2.7.b Working on an issue (2): Creating your issue branch**
 
 If you have not already done so, run `git checkout gh-pages` to switch the working directory to the `gh-pages` branch and then update `gh-pages` with upstream changes as described above in Section 2.7.a. 
 
@@ -542,9 +543,12 @@ git checkout -b update-give-link-2093
 
 **Note:** No law of physics will break if you don't adhere to this scheme, but laws of git will break if you add spaces.
 
-We urge developers to be cautious using `git add`. In general it is not advisable to use `git add -all` or `git add .`. Rather, run `git status`, examine the output carefully, and then add only those files specifically related to the current issue. This will ensure that no extraneous files are included in the subsequent commit.  
+<sub>[Back to Table of Contents](#table-of-contents)</sub>
+
+#### **2.7.c Working on an issue (3): Testing your changes**
+
 
-When you've finished working on your issue, follow the steps below to prepare your changes to push to your repository.
+**_Santisecco's edits/additions_**
 
 ##### **i. A few notes regarding Docker:**
 
@@ -588,33 +592,44 @@ When you've finished working on your issue, follow the steps below to prepare yo
 
 <sub>[Back to Table of Contents](#table-of-contents)</sub>
 
-#### **2.7.c Working on an issue(3): Prepare your changes to push to your repository**
+#### **2.7.d Working on an issue(4): Prepare your changes to push to your repository**
 
 Once you are done with the work on your issue you will push it to your repository.  Before you can push your work to your repository, you will stage and commit your changes.  These two commands are similar to the save command that you have used to in other programs.
 
 **Note:** If you are using Visual studios code you can use the Git graphical user interface to stage your changes. For instructions check out the [Git Gui Wiki](https://github.com/hackforla/website/wiki/How-to-Use-Git-GUI-(Graphical-user-Interface)-in-Visual-Studios-Code)
 
-##### **i. Prepare repo changes (1): Use the `git add` command to stage your changes.**
+##### **i. Prepare repo changes (1): Use the `git status` then `git add` command to stage your changes.**
 
 This command prepares your changes before you commit them. You can stage files one at a time using the filename.
 
-Run this command if you want to **add changes from a specific file(s) to your commit record**:
+Run this command to see which files you have changed:
+```bash
+git status
+```
+Examine the output carefully: in the next step you want to be sure that you only those files specifically related to the current issue are added to the subsequent commit and ensure that no extraneous files are included.
+
+Run this command to **add each specific file(s) to your commit record**:
 ```bash
 git add “filename.ext”
 ```
 
-Run this command if you want to **add all changes to all file(s) to your commit record**:
+**Note:** This command can be used if you want to **add all changes to all file(s) to your commit record**:
 ```bash
 git add .
 ```
 
-##### **ii. Prepare repos changes (2): Use the `git status` command to see what files are staged.**
+**_However:_** We urge developers to be cautious using `git add`. In general it is not advisable to use `git add -all` or `git add .`. 
+
 
-This command will list the files that have been staged.  These are the files that will be committed (saved) when you run the next command, `git commit`. Please be sure all your staged changes are relevant to the issue you are working on. If you accidentally included unrelated changes, please unstage them before making this commit, and then make a new commit for the unrelated changes. (The commands for unstaging commits are provided in the output of your `git status` command.)
+##### **ii. Prepare repos changes (2): Use the `git status` command a second time to see what files are staged.**
+
+Use the `git status` command a second time to list the files that have been staged. These files are shown in green and they will be committed (saved) when you run the next command, `git commit`. Please be sure all your staged changes are relevant to the issue you are working on. If you accidentally included unrelated changes, please unstage them before making this commit. (If needed, make a new commit for the unrelated changes. The commands for unstaging commits are provided in the output of your `git status` command.)
 
 ```bash
 git status
 ```
+
+_WG comment: Following is not the command that is referenced in the output of the `git status` command- should this be deleted?_
 ##### **iii. Prepare repos changes (3): Use the `git reset HEAD` command to remove a staged file.**
 
 This command will remove a file that has been staged.  This file will not be committed (saved) when you run the next command, `git commit`. This only works if the wrong files were added, but they were not yet committed. The file will be removed from the staging area, but not actually deleted:
@@ -637,7 +652,7 @@ git commit -m “insert message here”
 
 <sub>[Back to Table of Contents](#table-of-contents)</sub>
 
-#### **2.7.d Working on an issue (4): Pulling from upstream before you push**
+#### **2.7.e Working on an issue (5): Pulling from upstream before you push**
 
 **IMPORTANT:** Before you push your local commits to your repository, sync your fork to the main Hack For LA website repository. You can sync your fork directly on GitHub by clicking "Sync Fork" at the right of the screen and then clicking "Update Branch":
 
@@ -686,7 +701,7 @@ From https://github.com/hackforla/website
 
 <sub>[Back to Table of Contents](#table-of-contents)</sub>
 
-#### **2.7.e Working on an issue (5): Incorporating changes from upstream**
+#### **2.7.f Working on an issue (6): Incorporating changes from upstream (only if needed)**
 
 Your fork of this repository on GitHub, and your local clone of that fork, will get out of sync with this (upstream) repository from time to time. (That's what has happened when you see something like "This branch is 1 commit behind hackforla:gh-pages" on the github website version of your hackforla repository.)
 
@@ -750,7 +765,7 @@ git checkout update-give-link-2093
 git merge gh-pages
 ```
 
-#### **2.7.f Working on an issue (6): Handling SSH authorization errors**
+#### **2.7.g Working on an issue (7): Handling SSH authorization errors (only if needed)**
 
 If you already have an SSH key that connects your computer with your GitHub account, you can skip this section (2.7.f).