fix: replace incorrect "eg." with "e.g." throughout project

Pull from Collab Guide [PR 55](Imageomics/Collaborative-distributed-science-guide#55)

Closes #54

Author: gwtaylor

docs/wiki-guide/Code-Checklist.md

@@ -19,7 +19,7 @@ This checklist provides an overview of essential and recommended elements to inc
     - [ ] Acknowledge source code dependencies and contributors.
     - [ ] Reference related datasets used in training or evaluation.
 - [ ] **Requirements File**: Provide a [file detailing software requirements](GitHub-Repo-Guide.md/#software-requirements-file), such as a `requirements.txt` or `pyproject.toml` for Python dependencies.
-- [ ] **Gitignore File**: GitHub has premade `.gitignore` files (see [github/gitignore](https://github.com/github/gitignore)) tailored to particular languages (eg., [R](https://github.com/github/gitignore/blob/main/R.gitignore) or [Python](https://github.com/github/gitignore/blob/main/Python.gitignore)), operating systems, etc.
+- [ ] **Gitignore File**: GitHub has premade `.gitignore` files (see [github/gitignore](https://github.com/github/gitignore)) tailored to particular languages (e.g., [R](https://github.com/github/gitignore/blob/main/R.gitignore) or [Python](https://github.com/github/gitignore/blob/main/Python.gitignore)), operating systems, etc.
 - [ ] **CITATION CFF**: This facilitates citation of your work, follow guidance provided in the [Repo Guide](GitHub-Repo-Guide.md/#citation).
 
 ### Data-Related

docs/wiki-guide/GitHub-Repo-Guide.md

@@ -82,7 +82,7 @@ Once a license has been chosen, add a `LICENSE.md` file to the root of the repos
 
 The `.gitignore` file is an important tool for maintaining a clean repository by ensuring that git will not track temp files of any and all your collaborators (no pesky `pycache` or `.DS_Store` files floating around).
 
-GitHub has premade `.gitignore` files which can be selected from a dropdown when creating a repo. They are available for review at [github/gitignore](https://github.com/github/gitignore) and are generally tailored to particular languages (eg., [R](https://github.com/github/gitignore/blob/main/R.gitignore) or [Python](https://github.com/github/gitignore/blob/main/Python.gitignore)), operating systems, etc. The initial choice can be updated as needed. In particular, we recommend selecting a template based on the primary language used for your work.
+GitHub has premade `.gitignore` files which can be selected from a dropdown when creating a repo. They are available for review at [github/gitignore](https://github.com/github/gitignore) and are generally tailored to particular languages (e.g., [R](https://github.com/github/gitignore/blob/main/R.gitignore) or [Python](https://github.com/github/gitignore/blob/main/Python.gitignore)), operating systems, etc. The initial choice can be updated as needed. In particular, we recommend selecting a template based on the primary language used for your work.
 
 If you or anyone on your team uses a Mac (or if you intend to encourage outside collaboration on this repo), add
 
@@ -95,7 +95,7 @@ at the end of the `.gitignore` file.
 
 ### Software Requirements File
 
-It is also advisable to include a machine-readable file with minimal software requirements for your project. For Python projects, this often takes the form of a `requirements.txt` file containing the packages and their versions that were used (eg., `pandas==2.0.1`). If you use `conda`, you may instead opt for an `environment.yml`. These are essential to ensuring the reproducibility and interoperability of your work (by yourself and others). Note that they should _**not**_ be listed in the README.
+It is also advisable to include a machine-readable file with minimal software requirements for your project. For Python projects, this often takes the form of a `requirements.txt` file containing the packages and their versions that were used (e.g., `pandas==2.0.1`). If you use `conda`, you may instead opt for an `environment.yml`. These are essential to ensuring the reproducibility and interoperability of your work (by yourself and others). Note that they should _**not**_ be listed in the README.
 
 For more information on managing these environments and generating such files programmatically, see the wiki entry [Virtual Environments](Virtual-Environments.md).
 
@@ -292,6 +292,6 @@ If you would like a specific branch, use `git clone -b <branch_name> <repo_url>`
 
 ### Workflow Summary
 
-Generally, repositories are organized around an Imageomics Project/Topic/Team, eg., butterflies. These broader topics may contain various projects organized under a GitHub [Team](https://github.com/orgs/Imageomics/teams) focused on that topic. Both [projects](https://github.com/orgs/Imageomics/projects?query=is%3Aopen) and [repositories](https://github.com/orgs/Imageomics/repositories) may be linked to teams, providing an organizational structure upon which to plan and manage tasks while maintaining a clear link/connection to the work being done on those tasks. Note that a project may encapsulate multiple repositories just as a repository may be referenced by multiple projects.
+Generally, repositories are organized around an Imageomics Project/Topic/Team, e.g., butterflies. These broader topics may contain various projects organized under a GitHub [Team](https://github.com/orgs/Imageomics/teams) focused on that topic. Both [projects](https://github.com/orgs/Imageomics/projects?query=is%3Aopen) and [repositories](https://github.com/orgs/Imageomics/repositories) may be linked to teams, providing an organizational structure upon which to plan and manage tasks while maintaining a clear link/connection to the work being done on those tasks. Note that a project may encapsulate multiple repositories just as a repository may be referenced by multiple projects.
 
 Ideally, each task will be linked to an issue in the relevant repository. Team members may then be assigned tasks, and asynchronous discussions about the task can be recorded on its issue page in the repository. To accomplish the task, a new branch should be created following the [branch naming conventions](#formatting-and-naming-conventions); do not work directly on the `main` branch. Once the task is completed, a pull request can be opened to merge the changes into the main branch (see the [GitHub Workflow Guide](The-GitHub-Workflow.md) and the [PR Guide](The-GitHub-Pull-Request-Guide.md) for more details on this process). Reviewers may be assigned to each pull request to ensure compatibility and that the proposed solution functions as expected/needed; this is an opportunity for more dialogue.

docs/wiki-guide/HF_ModelCard_Template_Imageomics.md

@@ -17,7 +17,7 @@ model_description: # Add a short description (summary) of your model, this will
 
 NOTE: Add more tags (your particular animal, type of model and use-case, etc.).
 
-As with your GitHub Project repo, it is important to choose an appropriate license for your model. Alongside the appropriate stakeholders (eg., your PI, co-authors), select a license that is [Open Source Initiative](https://opensource.org/licenses) (OSI) compliant. You may also wish to consider adding a [RAIL license](https://www.licenses.ai/ai-licenses), which addresses responsible use.
+As with your GitHub Project repo, it is important to choose an appropriate license for your model. Alongside the appropriate stakeholders (e.g., your PI, co-authors), select a license that is [Open Source Initiative](https://opensource.org/licenses) (OSI) compliant. You may also wish to consider adding a [RAIL license](https://www.licenses.ai/ai-licenses), which addresses responsible use.
 For more information on how to choose a license and why it matters, see [Choose A License](https://choosealicense.com) and [A Quick Guide to Software Licensing for the Scientist-Programmer](https://doi.org/10.1371/journal.pcbi.1002598) by A. Morin, et al.
 See the [Imageomics policy for licensing](https://imageomics.github.io/Imageomics-guide/wiki-guide/Digital-products-release-licensing-policy/) for more information.
 

docs/wiki-guide/Hugging-Face-Repo-Guide.md

@@ -57,7 +57,7 @@ at the end of the `.gitignore` file.
 
 #### gitattributes
 
-The `.gitattributes` file determines file patterns to be tracked by [`git LFS`](https://git-lfs.com/) (Git Large File Storage). The preset `gitattributes` file includes many binary file types, but you may need to add particular files if they get too large (eg., a large CSV, but do **NOT** store all CSV files with `git LFS`, just add the particular one or pattern). Pattern-matching can be done using `*`. You can either add the file (and appropriate pattern description) to the `.gitattributes` file, or add it in the command line:
+The `.gitattributes` file determines file patterns to be tracked by [`git LFS`](https://git-lfs.com/) (Git Large File Storage). The preset `gitattributes` file includes many binary file types, but you may need to add particular files if they get too large (e.g., a large CSV, but do **NOT** store all CSV files with `git LFS`, just add the particular one or pattern). Pattern-matching can be done using `*`. You can either add the file (and appropriate pattern description) to the `.gitattributes` file, or add it in the command line:
 
 ```
 git lfs track "my-big-list.csv"
@@ -69,7 +69,7 @@ Then add and commit the `.gitattributes` file as described below.
 
 Hugging Face also has a pull request (PR) feature, though the process is a bit different from GitHub.
 
-As with GitHub, you can interact through the web browser or a command line interface (eg., terminal on Mac). However, instead of the `create new branch` option, there is a `create new pull request` option. It is still preferable to avoid committing everything directly to main. To make further changes to the particular PR created on the browser, one must first clone the repo:
+As with GitHub, you can interact through the web browser or a command line interface (e.g., terminal on Mac). However, instead of the `create new branch` option, there is a `create new pull request` option. It is still preferable to avoid committing everything directly to main. To make further changes to the particular PR created on the browser, one must first clone the repo:
 
 ```
 git clone <repo-url> 

docs/wiki-guide/The-Hugging-Face-Workflow.md

@@ -4,7 +4,7 @@
 
 Hugging Face also has a pull request (PR) feature, though the process is a bit different from GitHub.
 
-As with GitHub, you can interact through the web browser or a command line interface (eg., terminal on Mac). However, instead of the `create new branch` option, there is a `create new pull request` option. It is still preferable to avoid committing everything directly to main. To make further changes to the particular PR created on the browser, one must first clone the repo:
+As with GitHub, you can interact through the web browser or a command line interface (e.g., terminal on Mac). However, instead of the `create new branch` option, there is a `create new pull request` option. It is still preferable to avoid committing everything directly to main. To make further changes to the particular PR created on the browser, one must first clone the repo:
 
 ```
 git clone <repo-url> 

docs/wiki-guide/Two-Repo-Problem.md

@@ -196,7 +196,7 @@ git push --set-upstream origin v1
 At this point the main branch of the public repo should match the main branch of the private repo.
 Additional changes should be made only to the private repo, preferably using a branch.
 See [Github-Workflow](The-GitHub-Workflow.md) for more details.
-When you are ready to release a new version of the code in the private repo follow the [Merge Private to Public instructions](#merge-private-to-public) again using a new version branch name (eg. `v2`).
+When you are ready to release a new version of the code in the private repo follow the [Merge Private to Public instructions](#merge-private-to-public) again using a new version branch name (e.g., `v2`).
 
 ***
 

docs/wiki-guide/Virtual-Environments.md

@@ -32,7 +32,7 @@ conda env export --no-builds --from-history | grep -v "prefix" > environment.yml
 For virtual environments using `pip` to install packages (Python environments), use `python -m pip freeze` to print a list of packages (and their versions) installed in the environment.
 
 !!! info "Command extension"
-    - `python -m pip freeze > requirements.txt` will populate a `requirements.txt` file with all these packages and versions listed (eg., `pandas==2.0.1`).
+    - `python -m pip freeze > requirements.txt` will populate a `requirements.txt` file with all these packages and versions listed (e.g., `pandas==2.0.1`).
         - **Note:** This will _not_ give only minimum software requirements, but will also print _all_ dependencies.
     - Install this machine-readable file with `pip install -r requirements.txt` when in the appropriate folder.
     - For more information, see the [pip documentation](https://pip.pypa.io/en/stable/cli/pip_freeze/).

docs/wiki-guide/When-to-think-about-branch-protections.md

@@ -10,7 +10,7 @@ Generally speaking, once the set of potential users exceeds that of repository d
 
 ## How to Implement Branch Protections
 
-From your repository, navigate to "Settings" and select "Branches" from the left toolbar. Provide the name of the branch you would like to protect, for instance `main`, and select the rules that you want applied to the branch. It is also possible to set the rules for branches matching a particular pattern (eg., type `*release*` to apply the rules to any branch containing the word `release`). You can also edit branch protection rules from this page.
+From your repository, navigate to "Settings" and select "Branches" from the left toolbar. Provide the name of the branch you would like to protect, for instance `main`, and select the rules that you want applied to the branch. It is also possible to set the rules for branches matching a particular pattern (e.g., type `*release*` to apply the rules to any branch containing the word `release`). You can also edit branch protection rules from this page.
 
 The example below shows the addition of branch protection rules for `main` that require a pull request and that it be approved prior to merging. It also will remove approval if other changes are added that require approval.
 
@@ -40,7 +40,7 @@ We choose to apply these to the default branch (`main` or `master`).
 /// caption
 ///
 
-As with branch protections, it is also possible to set the rules for branches matching a particular pattern (eg., type `*release*` to apply the rules to any branch containing the word `release`). We will do this for `gh-pages`.
+As with branch protections, it is also possible to set the rules for branches matching a particular pattern (e.g., type `*release*` to apply the rules to any branch containing the word `release`). We will do this for `gh-pages`.
 
 ![Add target pattern for gh-pages under target branches for branch ruleset](images/GH-branch-protections/382111988-20d6499e-fb12-4335-8b8d-76ac6b989528.png){ loading=lazy }
 /// caption