Clean up punctuation on two pages

about/licenses/index.md

@@ -141,7 +141,7 @@ Cardioid is distributed under the terms of the MIT license. All new contribution
 
 **[SPDX](https://spdx.org/) is an emerging standard for concisely labeling source code with license information.** While it is not a requirement, we encourage you to use SPDX identifiers in your code, as they significantly reduce the amount of license boilerplate included in each source file.
 
-SPDX provides a standard [list of license identifiers](https://spdx.dev/ids/) that can be used to label code.  To use SPDX identifiers in your project, you should find your license's short identifier in the list, and add a special `SPDX-License-Identifier` line to your `README.md`. For example, if your code is licensed under the `MIT` license like [Cardioid](https://github.com/llnl/cardioid), you would add this at the bottom of your README file:
+SPDX provides a standard [list of license identifiers](https://spdx.dev/ids/) that can be used to label code.  To use SPDX identifiers in your project, you should find your license's short identifier in the list and add a special `SPDX-License-Identifier` line to your `README.md`. For example, if your code is licensed under the `MIT` license like [Cardioid](https://github.com/llnl/cardioid), you would add this at the bottom of your README file:
 
 ```bash
 SPDX-License-Identifier: MIT
@@ -171,7 +171,7 @@ For example, visit the [Spack](https://github.com/spack/spack) or [Flux](https:/
 
 As mentioned above, the default assumption for open source projects is ["inbound license = outbound license"](https://opensource.guide/legal/), i.e., contributors provide their code under the same license under which the code is distributed. If this is not enough assurance for your project, you may use the [Developer Certificate of Origin (DCO)](https://developercertificate.org/) with your project.
 
-**In this model, you can require contributors to use Git's [sign-off](https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for) feature to acknowledge the DCO.** This is *not* a license nor a CLA, but instead is a positive assertion by the contributor that they are authorized to make the contribution they are making. You should document your project's requirement of DCO sign-off in your `README.md` or your [`CONTRIBUTING.md` file](https://help.github.com/articles/setting-guidelines-for-repository-contributors/).
+**In this model, you can require contributors to use Git's [sign-off](https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for) feature to acknowledge the DCO.** This is *not* a license nor a CLA but instead is a positive assertion by the contributor that they are authorized to make the contribution they are making. You should document your project's requirement of DCO sign-off in your `README.md` or your [`CONTRIBUTING.md` file](https://help.github.com/articles/setting-guidelines-for-repository-contributors/).
 
 You are not required to use the DCO, and it may add overhead to your process that deters potential contributors. **Unless you feel that you need this level of assurance for your project, we recommend that you simply rely on the default inbound = outbound assumption.**
 

about/policies/index.md

@@ -25,15 +25,15 @@ IM #975025
 
 ### About RADIUSS
 
-The [RADIUSS](https://computing.llnl.gov/projects/radiuss) project promotes and supports a broad set of open source software developed over many years at [Lawrence Livermore National Laboratory (LLNL)](https://www.llnl.gov) for use outside of their primary funding organization and within the broader scientific research community. With these libraries and tools we cover a wide range of features a team would need to develop a modern scientific simulation code, particularly when targeting High Performance Computing (HPC). Each of these products are used in applications that support the LLNL science mission, and will be supported and continuously developed for the foreseeable future. These are not research projects that will simply vanish if a lead developer finds other interests - but well-supported software backed by programs and sponsors, and supplemented with support through the RADIUSS project for broader use and external engagement.
+The [RADIUSS](https://computing.llnl.gov/projects/radiuss) project promotes and supports a broad set of open source software developed over many years at [Lawrence Livermore National Laboratory (LLNL)](https://www.llnl.gov) for use outside of their primary funding organization and within the broader scientific research community. With these libraries and tools, we cover a wide range of features a team would need to develop a modern scientific simulation code, particularly when targeting High Performance Computing (HPC). Each of these products are used in applications that support the LLNL science mission and will be supported and continuously developed for the foreseeable future. These are not research projects that will simply vanish if a lead developer finds other interests—but well-supported software backed by programs and sponsors as well as supplemented with support through the RADIUSS project for broader use and external engagement.
 
 ### Policies and Guidelines
 
-As part of the RADIUSS project, these open source products follow a set of policies and guidelines (listed below) based on best practices for open source development learned and adopted through years of research and development supporting production software running on the worlds largest supercomputers. Some of these policies were derived directly or indirectly from other similar documents [^bss] [^xsdk] [^sl] [^wsc] listed at the bottom of this page. By sharing these policies publicly, we hope to encourage others to adopt similar standards for the betterment of the open source software community, and welcome a [dialogue](mailto:radiuss-request@llnl.gov) on where we could improve.
+As part of the RADIUSS project, these open source products follow a set of policies and guidelines (listed below) based on best practices for open source development learned and adopted through years of research and development supporting production software running on the world's largest supercomputers. Some of these policies were derived directly or indirectly from other similar documents [^bss] [^xsdk] [^sl] [^wsc] listed at the bottom of this page. By sharing these policies publicly, we hope to encourage others to adopt similar standards for the betterment of the open source software community, and welcome a [dialogue](mailto:radiuss-request@llnl.gov) on where we could improve.
 
 These policies and guidelines are not meant to be a comprehensive set of recommendations for good software quality assurance (SQA) practices (although many of them do promote that). Instead, these are policies that we feel are particularly important for developers of open source software to follow. We strongly believe that open source software will not succeed by just being "put out there". These policies are our attempt to capture the things we feel are most important to a successful open source project, beyond just good SQA practices that any software engineer would promote.
 
-We intend to continuously evolve these policies and guidelines in the future. In particular, tools mentioned are not eternal and best practices evolve rapidly, demanding flexibility in our approaches. However, we attempted to make these recommendation as generic as possible, so that they could apply to the various types of projects RADIUSS supports, and likewise may serve to others. While we try not to interfere in project's management, with found it important and relevant to focus our support effort on a subset of fundamental tools, so that knowledge and practices can easily be shared, and for the sake of interoperability.
+We intend to continuously evolve these policies and guidelines in the future. In particular, tools mentioned are not eternal and best practices evolve rapidly, demanding flexibility in our approaches. However, we attempted to make these recommendations as generic as possible, so that they could apply to the various types of projects RADIUSS supports and, likewise, may serve to others. While we try not to interfere in a project's management, with found it important and relevant to focus our support effort on a subset of fundamental tools, so that knowledge and practices can easily be shared, and for the sake of interoperability.
 
 RADIUSS and the projects it covers are open-source and primarily (or by now, exclusively) use [GitHub](https://github.com) for repository management. These policies and guidelines are themselves part of the [GitHub repository](https://github.com/LLNL/llnl.github.io) that automates the building and updating of [LLNL's Software Portal](https://software.llnl.gov), to which you are welcome to submit an issue or pull request to help us evolve these policies.