docs: encourage contribution

Refactor project documentation to make it clear that this is a community
project, encouraging organizations and individuals to contribute their
implementations for others to access and use. Additionally, adjust the
tone when referencing project ownership to be more inclusive.

docs/source/CHANGELOG.md

@@ -2,7 +2,7 @@
 
 ## Release Process and Guidelines
 
-In our project, we adhere to the principles of [Semantic Versioning](http://semver.org/) when it comes to our releases. By following this release process, we ensure the orderly progression of our project while maintaining compatibility and providing necessary bug fixes and improvements.
+This project follows the principles of [Semantic Versioning](http://semver.org/) for releases. This helps us maintain an orderly progression to the project while maintaining compatibility and providing necessary bug fixes and improvements.
 
 *Major Releases*: A major release introduces significant changes, including those that break compatibility with previous versions. These releases are identified with a version number in the format of `X.0.0`. For instance, if the previous release was `1.2.7`, the next major version will be labeled as `2.0.0`.
 

docs/source/dev/conduct.rst

@@ -6,7 +6,7 @@ Code of Conduct
 Our Pledge
 ----------
 
-In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in this project and community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
 
 Our Standards
 --------------

docs/source/dev/contributing.rst

@@ -3,27 +3,25 @@
 Contributor's Guide
 ===================
 
-Welcome to our open source project! If you're reading this, it's likely because you're interested in contributing, and we sincerely appreciate your support! Open source projects thrive with the valuable contributions from individuals like you, and we're grateful for your consideration.
+Welcome to the open source community building this toolkit! We're thrilled you're interested in contributing – your ideas and efforts are what make this project thrive.
 
-This document provides guidelines for contributing to our project. To get started, we recommend reading this guide to familiarize yourself with our collaborative process. If you have any questions, feel free to reach out to our primary maintainer: `Colin Smith`_.
-
-.. _Colin Smith: https://github.com/clnsmth
+We encourage you to explore the guide and familiarize yourself with our collaborative development process. If you have any questions or need help getting started, feel free to reach out on our `GitHub issue`_ tracker.
 
 Be Courteous
 ------------
 
 In the spirit of collaboration, we emphasize the importance of maintaining a respectful and inclusive environment.
 
-In our project, we uphold a golden rule that applies to all forms of contribution, including bug reports and feature requests: treat everyone involved with respect. We value the diverse perspectives and experiences of our contributors and encourage constructive and courteous interactions.
+In this project, we uphold a golden rule that applies to all forms of contribution, including bug reports and feature requests: treat everyone involved with respect. We value the diverse perspectives and experiences of our contributors and encourage constructive and courteous interactions.
 
-See our :ref:`Code of Conduct <conduct>` for details.
+See the :ref:`Code of Conduct <conduct>` for details.
 
 .. _Code of Conduct: https://soso.readthedocs.io/en/latest/dev/conduct/
 
 Contribution Suitability
 ------------------------
 
-The final decision regarding the suitability of a contribution for the project rests with our project maintainers. While we carefully consider all contributions, there may be instances where certain contributions are not aligned with the project's current goals or needs, and as a result, they may be declined.
+The final decision regarding the suitability of a contribution for the project rests with the project maintainers. While we carefully consider all contributions, there may be instances where certain contributions are not aligned with the project's current goals or needs, and as a result, they may be declined.
 
 Need some feedback on whether your idea is suitable for the project? Open a `GitHub issue`_. We're happy to discuss your ideas and provide feedback!
 
@@ -32,6 +30,8 @@ Need some feedback on whether your idea is suitable for the project? Open a `Git
 Code Contributions
 ------------------
 
+Thinking about adding support for a new metadata standard?  The section titled :ref:`setting-up-a-new-metadata-conversion-strategy` provides a step-by-step guide.
+
 Steps for Submitting Code
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -78,7 +78,7 @@ style and format as it grows. We use `Black`_ for code formatting and `Pylint`_
 Documentation Contributions
 ---------------------------
 
-We greatly appreciate any efforts to enhance our documentation! The documentation files reside within the ``docs/`` directory and are written in `reStructuredText`_. We utilize `Sphinx`_ to generate a comprehensive suite of documentation. The API documentation is automatically generated by Sphinx from docstrings formatted according to `PEP 287`_.
+We greatly appreciate any efforts to enhance the project documentation! The documentation files reside within the ``docs/`` directory and are written in `reStructuredText`_. We utilize `Sphinx`_ to generate a comprehensive suite of documentation. The API documentation is automatically generated by Sphinx from docstrings formatted according to `PEP 287`_.
 
 Build the docs from the command line::
 
@@ -94,7 +94,7 @@ Build the docs from the command line::
 Bug Reports
 -----------
 
-Bug reports play a crucial role in our project! However, before submitting a bug report, we kindly request you to check the existing `GitHub issues`_ to ensure that the bug hasn't been reported before.
+We value your help in improving this project! To avoid duplicate reports, it's helpful to quickly check the existing `GitHub issues`_  to see if the bug has already been reported.
 
 If you are reporting a bug, please use the `Bug report`_ issue template. We appreciate it!
 
@@ -104,7 +104,7 @@ If you are reporting a bug, please use the `Bug report`_ issue template. We appr
 Feature Requests
 ----------------
 
-Feature requests help our project grow with the user community. If you have an idea for a new feature, we'd love to hear about it! Before submitting a feature request, we kindly request you to check the existing `GitHub issues`_ to ensure that the feature hasn't been requested.
+Feature requests help this project grow with the user community. If you have an idea for a new feature, we'd love to hear about it! Before submitting a feature request, we kindly request you to check the existing `GitHub issues`_ to ensure that the feature hasn't been requested.
 
 If you are proposing a feature, please use the `Feature request`_ issue template. Thanks!
 
@@ -115,6 +115,6 @@ If you are proposing a feature, please use the `Feature request`_ issue template
 Commit Messages
 ---------------
 
-Commit messages are incredibly valuable for understanding our project's code. When crafting your commit message, please provide context about the changes being made and the reasons behind them.
+Commit messages are incredibly valuable for understanding the project's code. When crafting your commit message, please provide context about the changes being made and the reasons behind them.
 
 To ensure readability, we recommend to keep the commit message header under 52 characters and the body within 72 characters.

docs/source/dev/design.rst

@@ -3,7 +3,7 @@
 Project Design
 ==============
 
-Welcome to the design document for our project! This document provides an in-depth overview of the architectural design, key components, and design principles behind our work. It aims to enhance your understanding of our project's design philosophy and empower you to contribute effectively.
+Welcome to the design document for `soso`! This document provides an in-depth overview of the architectural design, key components, and design principles behind our work. It aims to enhance your understanding of our project's design philosophy and empower you to contribute effectively.
 
 We encourage you to explore this document and reach out with any questions or suggestions. Your feedback is invaluable as we continuously improve and evolve our project.
 
@@ -61,7 +61,7 @@ Metadata Mapping
 
 We utilize the `Simple Standard for Sharing Ontological Mappings`_ (SSSOM) for semantic mapping metadata standards to SOSO. SSSOM provides a framework for expressing the match precision and other essential information to guide developer implementations.
 
-We apply SSSOM following `SSSOM guidelines`_, with some nuanced additions tailored to our project's needs. One such addition is the inclusion of a `subject_category` column, which aids in grouping and improving the readability of highly nested `subject_id` values. Additionally, we've formatted `subject_id` values using an arbitrary hierarchical path-like expression, enhancing clarity for the reader in understanding which property is being referenced. Note, while this path is human-readable, it is not machine-actionable.
+We apply SSSOM following `SSSOM guidelines`_, with some nuanced additions tailored to the project's needs. One such addition is the inclusion of a `subject_category` column, which aids in grouping and improving the readability of highly nested `subject_id` values. Additionally, we've formatted `subject_id` values using an arbitrary hierarchical path-like expression, enhancing clarity for the reader in understanding which property is being referenced. Note, while this path is human-readable, it is not machine-actionable.
 
 Beyond these general differences, each metadata standard's mapping may have unique nuances that should be considered. These are documented in each metadata standard's SSSOM.yml file, located in the `src/soso/data/` directory.
 
@@ -137,13 +137,15 @@ This approach ensures that even backward-incompatible changes introduced between
 Customization
 -------------
 
-The Strategy Pattern employed in our application enables a high degree of user customization to solve common challenges:
+The Strategy Pattern employed in this application enables a high degree of user customization to solve common challenges:
 
 * Properties that don’t map from a metadata standard but require external data, such as dataset landing page URLs.
 * Properties requiring custom processing due to community-specific application of metadata standards.
 
 These cases can be addressed by providing information as `kwargs` to the convert function, which overrides properties corresponding to `kwargs` key names, or by modifying existing strategy methods through method overrides. For further details, refer to the user :ref:`quickstart`.
 
+.. _setting-up-a-new-metadata-conversion-strategy:
+
 Setting Up a New Metadata Conversion Strategy
 ---------------------------------------------
 

docs/source/dev/maintaining.rst

@@ -5,12 +5,12 @@ Maintainers Guide
 
 Many thanks for your help maintaining our project! Without your contribution, development would be considerably slower and the user community left waiting longer.
 
-This document complements the `Contributor's Guide <contributing.html>`_ by providing additional steps for integrating contributions into our project's code base. As a maintainer, you are also a contributor, so please use the contributor guide when making changes in order to keep the development process open and consistent (note :ref:`developing-features-as-a-maintainer`).
+This document complements the `Contributor's Guide <contributing.html>`_ by providing additional steps for integrating contributions into the project's code base. As a maintainer, you are also a contributor, so please use the contributor guide when making changes in order to keep the development process open and consistent (note :ref:`developing-features-as-a-maintainer`).
 
 Be Courteous
 ------------
 
-Sometimes we need to meet contributors halfway. This means more work on our part but for benefit of our project and community. Please be courteous and patient.
+Sometimes we need to meet contributors halfway. This means more work on our part but for benefit of the project and community. Please be courteous and patient.
 
 If you are unable to respond fully to a pull request or issue in a timely manner, please let the contributor know that you will get to it as soon as you can.
 
@@ -158,7 +158,7 @@ CI Workflow
 The CI workflow is run on each pull request and push to the `development` and `main` branches. It performs the following steps:
 
 1. Formats code in *src/* and *tests/* using `Black`_. This check is strictly enforced and will fail the workflow.
-2. Analyzes code in *src/* and *tests/* using our project's `Pylint`_ configuration (see :ref:`code-format-and-analysis`). This check is not strictly enforced and will not fail the workflow. However, generally, Pylint recommendations should be followed.
+2. Analyzes code in *src/* and *tests/* using the project's `Pylint`_ configuration (see :ref:`code-format-and-analysis`). This check is not strictly enforced and will not fail the workflow. However, generally, Pylint recommendations should be followed.
 3. Runs tests in *tests/* using `Pytest`_. This check is strictly enforced and will fail the workflow.
 4. Builds the documentation (see :ref:`documentation-contributions`). This check is strictly enforced and will fail the workflow.
 

docs/source/user/quickstart.rst

@@ -3,7 +3,7 @@
 Quickstart
 ==========
 
-Welcome to the Quickstart guide! Whether you're a beginner or experienced developer, this guide helps you install our package, set up dependencies, and explore core functionalities.
+Welcome to the Quickstart guide! Whether you're a beginner or experienced developer, this guide helps you install the package, set up dependencies, and explore core functionalities.
 
 Installation
 ------------

docs/source/user/support.rst

@@ -3,7 +3,6 @@
 Support and Assistance
 ======================
 
-If you have any inquiries or require assistance regarding `soso`, whether it's a general question, you've encountered unexpected behavior, or you wish to request a new feature, we encourage you to seek support by filing an issue on our `GitHub repository`_ or contact our primary maintainer: `Colin Smith`_.
+If you have any inquiries or require assistance regarding `soso`, whether it's a general question, you've encountered unexpected behavior, or you wish to request a new feature, we encourage you to seek support by filing an issue on our `GitHub repository`_.
 
 .. _GitHub repository: https://github.com/clnsmth/soso/issues
-.. _Colin Smith: https://github.com/clnsmth