From f60a246f1ddb919bbcb6a65b7950e655df8a4541 Mon Sep 17 00:00:00 2001 From: Graham Taylor Date: Wed, 28 Jan 2026 13:21:02 -0500 Subject: [PATCH] fix: replace incorrect "eg." with "e.g." throughout project Closes #54 --- docs/wiki-guide/Code-Checklist.md | 2 +- docs/wiki-guide/GitHub-Repo-Guide.md | 6 +++--- docs/wiki-guide/HF_DatasetCard_Template_ABC.md | 2 +- docs/wiki-guide/HF_ModelCard_Template_ABC.md | 2 +- docs/wiki-guide/HF_ModelCard_Template_Imageomics.md | 2 +- docs/wiki-guide/Hugging-Face-Repo-Guide.md | 4 ++-- docs/wiki-guide/The-Hugging-Face-Workflow.md | 2 +- docs/wiki-guide/Two-Repo-Problem.md | 2 +- docs/wiki-guide/Virtual-Environments.md | 2 +- docs/wiki-guide/When-to-think-about-branch-protections.md | 4 ++-- 10 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/wiki-guide/Code-Checklist.md b/docs/wiki-guide/Code-Checklist.md index 9a9179a..01b85f5 100644 --- a/docs/wiki-guide/Code-Checklist.md +++ b/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 diff --git a/docs/wiki-guide/GitHub-Repo-Guide.md b/docs/wiki-guide/GitHub-Repo-Guide.md index 64e0e3c..0c49d59 100644 --- a/docs/wiki-guide/GitHub-Repo-Guide.md +++ b/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). @@ -295,6 +295,6 @@ If you would like a specific branch, use `git clone -b ` ### 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. diff --git a/docs/wiki-guide/HF_DatasetCard_Template_ABC.md b/docs/wiki-guide/HF_DatasetCard_Template_ABC.md index acb59fc..1b120e3 100644 --- a/docs/wiki-guide/HF_DatasetCard_Template_ABC.md +++ b/docs/wiki-guide/HF_DatasetCard_Template_ABC.md @@ -17,7 +17,7 @@ description: # Add a short description (summary) of your dataset, this will rend 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 dataset. The default license is [CC0](https://creativecommons.org/publicdomain/zero/1.0/) (public domain dedication, see [Dryad's explanation of why to use CC0](https://blog.datadryad.org/2023/05/30/good-data-practices-removing-barriers-to-data-reuse-with-cc0-licensing/)). Alongside the appropriate stakeholders (eg., your PI, co-authors), select a license that is following the guidelines set forth in the [ABC Digital Products Release and Licensing Policy](https://ABC-Center.github.io/ABC-guide/wiki-guide/Digital-products-release-licensing-policy/). For Datasets, this would be public domain or terms no more restrictive than requiring attribution (e.g., [CC-BY](https://creativecommons.org/licenses/by/4.0/)). +As with your GitHub Project repo, it is important to choose an appropriate license for your dataset. The default license is [CC0](https://creativecommons.org/publicdomain/zero/1.0/) (public domain dedication, see [Dryad's explanation of why to use CC0](https://blog.datadryad.org/2023/05/30/good-data-practices-removing-barriers-to-data-reuse-with-cc0-licensing/)). Alongside the appropriate stakeholders (e.g., your PI, co-authors), select a license that is following the guidelines set forth in the [ABC Digital Products Release and Licensing Policy](https://ABC-Center.github.io/ABC-guide/wiki-guide/Digital-products-release-licensing-policy/). For Datasets, this would be public domain or terms no more restrictive than requiring attribution (e.g., [CC-BY](https://creativecommons.org/licenses/by/4.0/)). For more information on how to choose a license and why it matters, see [Choose A License](https://choosealicense.com). List of [HF license identifiers](https://huggingface.co/docs/hub/en/repositories-licenses) (for yaml). See more options for the above information by clicking "edit dataset card" on your repo. diff --git a/docs/wiki-guide/HF_ModelCard_Template_ABC.md b/docs/wiki-guide/HF_ModelCard_Template_ABC.md index f205729..12bac2d 100644 --- a/docs/wiki-guide/HF_ModelCard_Template_ABC.md +++ b/docs/wiki-guide/HF_ModelCard_Template_ABC.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 [ABC Global Center policy for licensing](https://docs.google.com/document/d/1SlITG-r7kdJB6C8f4FCJ9Z7o7ccwldZoSRJKjhRAWVA/edit#heading=h.c1sxg0wsiqru) for more information. diff --git a/docs/wiki-guide/HF_ModelCard_Template_Imageomics.md b/docs/wiki-guide/HF_ModelCard_Template_Imageomics.md index b415056..36b4f30 100644 --- a/docs/wiki-guide/HF_ModelCard_Template_Imageomics.md +++ b/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. diff --git a/docs/wiki-guide/Hugging-Face-Repo-Guide.md b/docs/wiki-guide/Hugging-Face-Repo-Guide.md index 0f187d6..ea2902e 100644 --- a/docs/wiki-guide/Hugging-Face-Repo-Guide.md +++ b/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 diff --git a/docs/wiki-guide/The-Hugging-Face-Workflow.md b/docs/wiki-guide/The-Hugging-Face-Workflow.md index 8419117..1e0d4ec 100644 --- a/docs/wiki-guide/The-Hugging-Face-Workflow.md +++ b/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 diff --git a/docs/wiki-guide/Two-Repo-Problem.md b/docs/wiki-guide/Two-Repo-Problem.md index 6966578..050a07f 100644 --- a/docs/wiki-guide/Two-Repo-Problem.md +++ b/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`). *** diff --git a/docs/wiki-guide/Virtual-Environments.md b/docs/wiki-guide/Virtual-Environments.md index 5d16944..026b3e0 100644 --- a/docs/wiki-guide/Virtual-Environments.md +++ b/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/). diff --git a/docs/wiki-guide/When-to-think-about-branch-protections.md b/docs/wiki-guide/When-to-think-about-branch-protections.md index 02ef0d5..b3440e4 100644 --- a/docs/wiki-guide/When-to-think-about-branch-protections.md +++ b/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