Merge branch 'main' into issue-101-ci

Author: riverma

docs/about/README.md

@@ -6,25 +6,25 @@ sidebar_position: 1
 
 > _A shared resource for discussing, iterating and referencing best practices in software lifecycle process improvements for multi-mission space and ground software_
 
-[📖 View our Infographic (PDF)](https://github.com/NASA-AMMOS/slim/files/8534342/SLIM-Infographic.pdf)
+[📖 View our Infographic (PDF)](SLIM-Infographic.pdf)
 
 Software Lifecycle Improvement & Modernization (SLIM) is a project focused on collecting, developing, and disseminating best practices and process improvement strategies in NASA multi-mission software development lifecycle ecosystems. SLIM represents both a community of contributors as well as a continually evolving repository for best practices documentation.
 
 ## Scope
 
 There are three key areas within the software development lifecycle improvement space that SLIM focuses on providing best practice guidance for:
 
-![SLIM-scope](https://user-images.githubusercontent.com/3129134/164510892-e95d6091-2038-43d5-9d4d-4880bd0b068f.png)
+![SLIM-scope](/img/scope.png)
 
 ## Process
 
 We reach out to community member projects, and solicit input on outstanding process improvement needs, including the respective needs' relative ranking in importance / criticality. A few needs are chosen to focus active contributor time upon - seeking to develop best practice guides, including items such as use case lists, trade-studies, reference architectures and starter kits. 
 
-![SLIM-community-process](https://user-images.githubusercontent.com/3129134/164385744-3ba6c442-e4a8-41df-9f64-44b8faa9562a.png)
+![SLIM-community-process](/img/community-process.png)
 
 Once prioritized needs are identified, contributors go through a series of steps to create best practice guides for the community. 
 
-![SLIM-dev-process](https://user-images.githubusercontent.com/3129134/164385960-911bff81-9218-4ba3-bcee-b60284a8b05c.png)
+![SLIM-dev-process](/img/dev-process.png)
 
 More information on our development process for best practice guides can be found in our [Contributing Guide](docs/contribute/contributing/development-process).
 
@@ -40,17 +40,17 @@ The following list of projects are currently SLIM member projects:
 <ul>
         <li>
             <a href="https://github.com/nasa-ammos/" rel="NASA AMMOS">
-                <img src="https://avatars.githubusercontent.com/u/37851411?s=200&v=4" alt="NASA AMMOS" />
+                NASA AMMOS
             </a>
         </li>
         <li>
             <a href="https://github.com/unity-sds/" rel="Unity SDS">
-                <img src="https://user-images.githubusercontent.com/3129134/163255685-857aa780-880f-4c09-b08c-4b53bf4af54d.png" alt="Unity SDS" />
+                Unity SDS
             </a>
         </li>
         <li>
             <a href="https://github.com/hysds/" rel="HySDS">
-                <img src="https://user-images.githubusercontent.com/3129134/161156679-c3dcec08-b6af-44e4-910c-5ec82ef18649.png" alt="HySDS" />
+                HySDS
             </a>
         </li>
 </ul>

docs/about/SLIM-Infographic.pdf

@@ -1,21 +1,61 @@
 # Change Log
 
-A change log provides a *human readable* list of significant changes, additions, deprecations, removals for software over time. It is meant to be able to be read by *people*. Change logs should be documented within a file called `CHANGELOG.md` and be updated per key release. See [semantic release](https://semver.org) for guidance on releasing cycles and versioning of your software. 
+<pre align="center">A guide for setting up a log to document software changes in a human-centric format.</pre>
 
-⚠️ A `CHANGELOG.md` can replicate wording from a releases page (e.g. GitHub Releases), but should not be left out *in place of* a releases page. Down-stream inheritors of your software may not have access to your releases page, and will expect a `CHANGELOG.md` to be present as part of your software distribution.
+## Introduction
 
-## Keep a Changelog
+**Background**: A change log is a vital tool for documenting significant changes in software over time in a format accessible to humans. It plays a critical role in conveying the evolution of software, including additions, deprecations, and removals. This guide outlines the best practices for maintaining a `CHANGELOG.md` file, complementing release pages and enhancing software distribution transparency.
 
-This change log standard seeks to provide a template for *human readable* change logs, among other key guidance on the change logging process.
+**Use Cases**:
+- Documenting software changes for easy understanding and tracking.
+- Enhancing transparency in software development and release cycles.
+- Storing the history of significant changes independent of code hosts like GitHub.com
+---
 
-Starter Kit:
-- [Guidance](https://keepachangelog.com/en/1.0.0/#how)
-- [Demo 1](https://github.com/riverma/terraformly/blob/main/CHANGELOG.md)
-- [Demo 2](https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md)
-- [Webpage](https://keepachangelog.com/en/1.0.0/)
+## Prerequisites
 
-To leverage this template, make sure to do the following:
-1. Talk with your team about leveraging this template, and seek wide agreement before you adopt
-2. Copy the demo `CHANGELOG.md` above, and place in a file within your repository called `CHANGELOG.md` 
-3. Edit the `CHANGELOG.md` file with your specific release information. If you have many historic releases prior to the creation of this file, mark the latest release as the first entry, and commit to updating this for future releases as the happen.
-4. Add an entry to your `README.md` under the `Changelog` section to point to your `CHANGELOG.md` file.
+* Familiarity with semantic versioning and release cycles.
+* Basic knowledge of Markdown formatting.
+
+---
+
+## Quick Start
+
+**[⬇️ Keep a Changelog](https://keepachangelog.com/en/1.0.0/#how)**
+
+Download a template for creating a human-readable change log for your software project.
+
+---
+
+## Step-by-Step Guide
+
+1. **Team Agreement**: Discuss the importance of a change log with your team, emphasizing its value for transparency and communication.
+2. **Creating the Change Log**:
+   - Start a `CHANGELOG.md` in your repository.
+   - See demo use of the templates like [Demo 1](https://github.com/riverma/terraformly/blob/main/CHANGELOG.md) or [Demo 2](https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md) as a base.
+   - Customize the file with your project's release information.
+3. **Integrating with Project Documentation**:
+   - Link to the `CHANGELOG.md` from your project’s `README.md` to enhance visibility.
+
+---
+
+## Frequently Asked Questions (FAQ)
+
+- Q: Why is a `CHANGELOG.md` crucial even if there's a GitHub auto-generated release changes page?
+- A: It ensures future-proof accessibility of change information, especially for users who may not have access to the project's release page or if the software has changed hands. Moreover, its meant to be feature-centric and designed for people to understand, rather than GitHub's commit-oriented change reports. 
+
+---
+
+## Credits 
+
+**Authorship**:
+- [Rishi Verma](https://github.com/riverma)
+
+**Acknowledgements**:
+* This guide draws from the ["Keep a Changelog"](https://keepachangelog.com) standard and examples from various open source projects.
+
+---
+
+## Feedback and Contributions
+
+Feedback and contributions are encouraged to refine this guide. See our [contribution guidelines](https://nasa-ammos.github.io/slim/docs/contribute/contributing/).

docs/guides/documentation/change-log/README.md

@@ -1,11 +1,59 @@
-# Documentation Hosts 
+# Documentation Hosting
 
-## Use Cases
+<pre align="center">Guidance on selecting and implementing documentation hosting tools.</pre>
 
-See the possible use cases and mapping to recommended tools for hosting different types of documentation. Feel free to propose changes by submitting a pull request for the Markdown file on our GitHub. See [contribution guide](docs/about/README.md#for-adding-improvements-to-an-existing-best-practice-guide) for details.
+## Introduction
 
-- [Use Cases](use-cases)
+**Background**: Choosing the right platform for hosting various types of documentation is crucial for project success. This guide explores use cases for different documentation types and recommends tools for hosting user, developer, admin, API docs, and more, aiding in informed decision-making for documentation management.
 
-## Trade Studies
+**Use Cases**:
+- Hosting user, admin, developer, and API documentation.
+- Selecting appropriate platforms for different documentation needs.
+- Ensuring accessible and maintainable documentation for a variety of audiences.
 
-- [Trade Study: User/Dev/Admin/API Doc Hosting Frameworks](trade-study-hostingdocs-user)
+---
+
+## Prerequisites
+
+* Understanding of different types of documentation and their requirements.
+* Familiarity with various documentation hosting platforms and frameworks.
+
+---
+
+## Quick Start
+
+**[📔 Documentation Use Cases and Hosting Tools](use-cases)**
+
+See various use cases and then select corresponding tools for hosting different types of documentation.
+
+**[📔 Trade Study on Hosting Frameworks](trade-study-hostingdocs-user)**
+
+View a trade-study of documentation hosting tools that we recommend.
+
+---
+
+## Step-by-Step Guide
+
+1. **Identify Documentation Needs**: Assess your project's documentation requirements based on use cases. For use case mapping, consult our [Documentation Use Cases and Hosting Tools](use-cases) document. 
+2. **Choose Appropriate Tools**: Refer to the [Trade Study on Hosting Frameworks](trade-study-hostingdocs-user) to select the right tools for your documentation type based on features.
+3. **Implement and Maintain**: Set up your chosen documentation platforms and ensure they are regularly updated and maintained.
+
+---
+
+## Frequently Asked Questions (FAQ)
+
+- Q: How do I choose the right platform for hosting my project's documentation?
+- A: Consider the type of documentation (user, admin, developer, API), the audience, and the specific features offered by the hosting platforms.
+
+---
+
+## Credits 
+
+**Authorship**:
+- [Rishi Verma](https://github.com/riverma)
+
+---
+
+## Feedback and Contributions
+
+Feedback and contributions are welcome to enhance this guide. Visit our [contribution guidelines](https://nasa-ammos.github.io/slim/docs/contribute/contributing/).