Merge conflict

.gitignore

 .DS_Store
+site/*
\ No newline at end of file

CONTRIBUTING.md

+# Contributing Guide
+
+The goal of this document is to create a contribution process that:
+
+* Encourages new contributions.
+* Encourages contributors to remain involved.
+* Avoids unnecessary processes and bureaucracy whenever possible.
+* Creates a transparent decision making process which makes it clear how
+contributors can be involved in decision making.
+
+
+## Vocabulary
+
+* A **Contributor** is any individual creating or commenting on an issue or pull request.
+* A **Committer** is a subset of contributors who have been given write access to the repository.
+
+
+# Logging Issues
+
+Log an issue for any question or problem you might have. When in doubt, log an issue,
+any additional policies about what to include will be provided in the responses. The only
+exception is security disclosures which should be sent privately.
+
+Committers may direct you to another repository, ask for additional clarifications, and
+add appropriate metadata before the issue is addressed.
+
+
+## Reporting bugs
+
+Before submitting a bug report, please follow the checklist to help us address the bug efficiently:
+
+- Make sure you are using the latest version.
+- Check other open or closed issues within the project repository to see if other users have experienced the same bug. 
+- Regarding the bug:
+
+    - Detail the steps in reproducing the bug.
+    - Attach your input and output, if feasible.
+    - Attach the stack trace.
+    - Make note of your OS, Platform and Version.
+    - Make not of your environment configs (compiler, package manager, conda env dependencies)
+    - Verify that the bug is reproducible.
+
+# Contributions
+
+Any change to resources in this repository must be through pull requests. This applies to all changes
+to documentation, code, binary files, etc.
+
+:exclamation: No pull request can be merged without being reviewed.
+
+You may request a specific contributor who is most versed in the issue at hand to review your pull request. Once all the feedback is addressed, any automated tests pass, and the pull request is approved, then the PR may be merged in. 
+
+In the case of an objection being raised in a pull request by another committer, all involved
+committers should seek to arrive at a consensus by way of addressing concerns being expressed
+by discussion, compromise on the proposed change, or withdrawal of the proposed change.
+
+## First-time contributor
+When making a contribution for the first time, please add your name to the `.zenodo.json` file. We strongly recommend adding your affiliation and ORCiD to the `zenodo.json` file. These additions only have to happen once.

README.md

@@ -67,7 +67,7 @@ We use these four categories to cover the range of potential docs while clarifyi
 | **Has the Goal of** | Enabling Beginners    | Showing How To Solve A Problem | Give Detailed Written Explanations | Give Dry Descriptions of Libraries, Services and Apps |
 | **Example**  | Jupyter notebook with toy data on how to ingest and project images | A breakdown of quirks working with Themis Images  |   Write-up on how ISIS defines projections | ISIS library Doxygen reference |
  
-This website structure borrows from the [Divio documentation system](https://documentation.divio.com/), except adapted to more specifically adhere to how our software is already structured, renamed the categories to be more specific, and have more focus on the composition (or mode of writing) of the docs to reduce ambiguity. One can't expect any categorical structure for software documentation to be orthogonal to eachother. There will always exist some degree of overlap between categories as the quantity of documentation grows. Documentation in one category can easily have overlapping information with those in others. However, composition of the doc (e.g., jupyter notebook with an explicit starting and end point, short how-to guide with code examples but ambigious starting point and end point, written explanation without code, doxygen API reference) is less ambigious that whether or not your docs can be considered a guide or a tutorial.    
+This website structure borrows from the [Divio documentation system](https://documentation.divio.com/), except adapted to more specifically adhere to how our software is already structured, renamed the categories to be more specific, and have more focus on the composition (or mode of writing) of the docs to reduce ambiguity. One can't expect any categorical structure for software documentation to be orthogonal to each other. There will always exist some degree of overlap between categories as the quantity of documentation grows. Documentation in one category can easily have overlapping information with those in others. However, composition of the doc (e.g., jupyter notebook with an explicit starting and end point, short how-to guide with code examples but ambiguous starting point and end point, written explanation without code, doxygen API reference) is less ambiguous that whether or not your docs can be considered a guide or a tutorial.    
 
 
 ### Getting Started Tutorials
@@ -89,7 +89,7 @@ Good getting started docs should:
 Concrete things your tutorial needs: 
 
 - If your tutorial requires installing software, list what software and their versions and clear instructions on how to install them. Feel free to point to other points of the doc that already have boilerplate info like "Go here to read on how to set up a custom ISISPreferences file". 
-- If your tutorial has data, use generative data or data that is in the repo. Avoid external data dependencies. Before data is committed into the repo, check if [existing data can be re-used](./data/). If new data needs to be committed, make sure it is small so as not to increase the data burden.   
+- If your tutorial has data, use generative data or data that is in the repo. Avoid external data dependencies. Before data is committed into the repo, check if [existing data can be reused](./data/). If new data needs to be committed, make sure it is small so as not to increase the data burden.   
 - Make sure to make the lesson clear in the title. Also, make it clear in the tutorial with something like "Lessons learned in this tutorial:". 
 
 
@@ -105,7 +105,7 @@ How-to guides are much like recipes in a recipe book. Write how-to docs to solve
 Similar to getting started guides in that they explain to users how to perform some valuable tasks with the software, but distinct in that they:
 
 1. Solve practical problems for more experienced users
-1. Offer more ambiguous starting points; they should be re-usable in many different contexts 
+1. Offer more ambiguous starting points; they should be reusable in many different contexts 
 1. Can be much shorter than getting started docs
 
 Examples: 
@@ -136,5 +136,5 @@ Examples:
 Software manuals centered on the code of the library. These are generally links to the library's programmatically generated API docs. Think Sphinx docs and/or Doxygen-generated docs. 
 
 Examples: 
-* Programatically Generated Python/C++ API docs from inline doc strings
+* Programmatically Generated Python/C++ API docs from inline doc strings
 * RESTful API docs from an OpenAPI spec file 

code.json

@@ -65,7 +65,7 @@
     },
 
     "homepageURL": "https://code.usgs.gov/astrogeology/asc-public-docs/-/blob/main/README.md",
-    "downloadURL": "https://code.usgs.gov/astrogeology/asc-public-docs/-/archive/1.0.1/asc-public-docs-main.zip",
+    "downloadURL": "https://code.usgs.gov/astrogeology/asc-public-docs/-/archive/1.0.1/asc-public-docs-1.0.1.zip",
     "disclaimerURL": "https://code.usgs.gov/astrogeology/asc-public-docs/-/raw/1.0.1/DISCLAIMER.md",
     "repositoryURL": "https://code.usgs.gov/astrogeology/asc-public-docs.git",
     "vcs": "git",