Merge branch 'NASA-AMMOS:main' into main

.gitignore

@@ -5,3 +5,4 @@
 **/node_modules
 **/package-lock.json
 /build/**
+.DS_Store

docs/about/README.md

@@ -18,44 +18,62 @@ There are three key areas within the software development lifecycle improvement
 
 ## Our Process
 
-### Community Outreach 
+### 1. Ask Our Community
 
-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. 
+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. That being said, any external contributors are free to propose best practice guides to our project at any time in the form of a contribution. See our /slim/docs/contribute/submit-best-practice for more details.  
 
-![SLIM-community-process](/img/community-process.png)
+You can see our current prioritized list of community-ranked best practice development ideas in our [planning board](https://github.com/orgs/NASA-AMMOS/projects/3).
 
-### Standards-as-Code
+### 2. Develop Standards & Best Practices
 
-We use a technique we like to call "standards-as-code", which basically means that we develop best practices that are _patchable_ to existing or new community member project codebases or are _deployable_ to their infrastructure. Therefore, we target providing best practices in a way that is most easily can be infused into existing projects. This way, we are actually able to scale out our best practice dissemination widely to many projects at once. 
+We use a technique we like to call "standards-as-code", which basically means that we develop best practices that are _patchable_ to existing or new community member project codebases or are _deployable_ to their infrastructure. Therefore, we target providing best practices in a way that is most easily can be infused into existing SLIM community member projects. This way, we are actually able to scale out our best practice dissemination widely to many projects at once. For best practices that are not patchable to repositories, we ask our contributors to develop automation that can be run as a script or set of commands - and deploy these to SLIM community members through issue-tickets.
 
 ![SLIM-dev-process](/img/standards-as-code.png)
 
 More information on our development process for best practice guides can be found in our [Contributing Guide](docs/contribute/contributing/development-process).
 
+### 3. Publish Best Practices
+
+As mentioned above, we operate under a "standards-as-code" philosophy, which means that newly developed standards and best practices are directly infused into member projects through pull requests or issue tickets. This hands-on approach ensures that improvements are easily infusable into the SLIM community member repositories.
+
+To see the current adoption status and how these practices are being integrated into various SLIM community member projects, check out our leaderboard pages:
+
+- [NASA AMMOS Best Practice Leaderboard](https://github.com/NASA-AMMOS/slim-leaderboard/blob/main/examples/slim-ammos-leaderboard.md)
+- [Unity SDS Best Practice Leaderboard](https://github.com/NASA-AMMOS/slim-leaderboard/blob/main/examples/slim-unity-leaderboard.md)
+
 ## Our Community Members
 
-What does it mean to be a community member of SLIM? The following ideas apply to member projects:
+What does it mean to be a community member of SLIM? The following ideas apply to community member projects:
 - Has a representative (a point-of-contact) who interfaces with the SLIM effort
-- Active and timely feedback on SLIM issue ticket prioritization
 - Openness and willingness to infuse SLIM best practices 
+- Prioritizes contributing back to the SLIM project with best practice guides
 
-The following list of projects are currently SLIM member projects:
+The following list of public projects are currently SLIM community members:
 
 <ul>
         <li>
             <a href="https://github.com/nasa-ammos/" rel="NASA AMMOS">
                 NASA AMMOS
             </a>
+            <ul>
+                <li>Point of Contact: <a href="https://github.com/PaulMRamirez">@PaulMRamirez</a></li>
+            </ul>
         </li>
         <li>
             <a href="https://github.com/unity-sds/" rel="Unity SDS">
                 Unity SDS
             </a>
+            <ul>
+                <li>Point of Contact: <a href="https://github.com/mike-gangl">@mike-gangl</a></li>
+            </ul>
         </li>
         <li>
             <a href="https://github.com/hysds/" rel="HySDS">
                 HySDS
             </a>
+            <ul>
+                <li>Point of Contact: <a href="https://github.com/hookhua">@hookhua</a></li>
+            </ul>
         </li>
 </ul>
 
@@ -76,7 +94,17 @@ Finally, if you use any of our guides - please consider adding the following bad
 
 ### Contribute to Our Guides
 
-We're excited to see your contribution! Please see our [Contributing Guide](docs/contribute/contributing) on details for how to contribute. We accept many non-code contributions as well, so feel free to think creatively. 
+We'd be delighted to see your contribution! Please see our [Contributing Guide](docs/contribute/contributing) on details for how to contribute. We accept many non-code contributions as well, so feel free to think creatively. 
+
+### Join Our Community of Projects
+
+Interested in becoming a part of the SLIM community? We welcome new project members who are keen on improving software lifecycle processes within their projects. Joining is simple:
+
+1. **Publicly: Start a Discussion**: Head over to our [discussion forum](https://github.com/NASA-AMMOS/slim/discussions/new/choose) and file a new thread expressing your interest in joining SLIM. This is a great way to introduce your project and outline how you think SLIM could benefit you.
+
+2. **Privately: Contact Us**: You can directly contact [@riverma](https://github.com/riverma) or the [@slim-steering](https://github.com/orgs/NASA-AMMOS/teams/slim-steering) group on GitHub to express your desire to join. We'll have a chat, and try to identify which repositories in your project make sense for best practice infusion as well as identify a point-of-contact.
+
+Becoming a part of SLIM means not just receiving updates regarding our best practices and standards, but also receiving pull-requests and issue tickets that help streamline SLIM best practices more easily to your project (at no cost!). 
 
 ### Spread the Word
 

docs/contribute/contributing/development-process.md

@@ -29,8 +29,7 @@ Make sure people are aware you're working on a patch! Check out our [issue track
 
 Our project typically has the following branches available, make sure to fork either the default branch or a branch someone else already tagged with a particular issue ticket you're working with.
 - `main` - default branch, and contains mature SLIM deliverables and should be the typical branch you fork
-- `develop` - active development area for SLIM deliverables, and typically ahead of `main` 
-- `retype` - live rendering of SLIM website, auto-generated by changes committed to `main` branch via [a GitHub Action](https://github.com/NASA-AMMOS/slim/actions/workflows/retype.yml)
+- `gh-pages` - live rendering of SLIM website, auto-generated by changes committed to `main` branch via [a GitHub Action](https://github.com/NASA-AMMOS/slim/blob/main/.github/workflows/docusaurus.yml)
 
 ## Make your Modifications
 

docs/contribute/contributing/index.md

@@ -1,3 +1,7 @@
-# Contributing
+---
+title: Contributing 101
+---
+
+# Contributing 101
 
 Thanks for taking the time to consider contributing! We very much appreciate your time and effort. This document outlines the many ways you can contribute to our project, and provides detailed guidance on best practices. We look forward to your help!

docs/contribute/contributing/know-before-contribute.md

@@ -6,20 +6,6 @@ sidebar_position: 1
 
 Before you begin contributing to our project, it'll be a good idea to ensure you've satisfied the below pre-requisites. 
 
-## Developer Certificate of Origin (DCO)
-
-To accept your contributions for any kind of patch, you'll want to:
-1. Understand what a Developer Certificate of Origin is. See [this](https://wiki.linuxfoundation.org/dco) guide.
-2. Read and agree to the [terms](https://developercertificate.org) of the Developer Certificate of Origin.
-3. Remember to add your Sign-Off for each patch contribution you submit to our project via either:
-   1. By using the `-s` flag if using Git. See [these](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--s) instructions.
-   2. By including the following text in your patch contributions (i.e. pull requests)
-   ```
-   Signed-off-by: Full Name <email>
-   ``` 
-
-Reviewers reviewing your patch will look for the sign-off before deciding to accept your contribution.
-
 ## License
 
 Our project has our licensing terms, including rules governing redistribution, documented in our [LICENSE](https://nasa-ammos.github.io/slim/LICENSE) file. Please take a look at that file and ensure you understand the terms. This will impact how we, or others, use your contributions.