[pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

common-practices-tools/contribution/contrib-first.md

@@ -1,6 +1,6 @@
 # Contrib First
 
-Whenever we are building something that could be of use by more than one project or client, we build it as contributed work first, if our contract and security concerns allow for it.  Contrib First is an approach we take with both patches to FOSS software and new contributions.
+Whenever we are building something that could be of use by more than one project or client, we build it as contributed work first, if our contract and security concerns allow for it. Contrib First is an approach we take with both patches to FOSS software and new contributions.
 
 ## Rationale for contrib first
 
@@ -9,7 +9,7 @@ Whenever we are building something that could be of use by more than one project
 -   **Security** - contributing our work to an open source project like Drupal means it may receive security coverage by the Drupal security team and the public.
 -   **Avoiding the gift that never happens** - Clients are not typically supportive of taking working local software that was already built for them and in use by them, and then paying to move or refactor that software to become open source. The benefit is too small for the cost. By building it as contributed code first, there is no extra cost.
 -   **Development happens in the open** - The issues are public. The commits are public. Everyone can contribute improvements.
--   **Reliability** - A solution built for contribution is often better designed, and better documented than a local solution meant to "just get it done".  By putting our company and personal names on it publicly we commit to a quality product.  Releasing a FOSS solution also increases the number of testers and edge cases that can surface and reduce bugs in the code.
+-   **Reliability** - A solution built for contribution is often better designed, and better documented than a local solution meant to "just get it done". By putting our company and personal names on it publicly we commit to a quality product. Releasing a FOSS solution also increases the number of testers and edge cases that can surface and reduce bugs in the code.
 -   **Scalability** - Contributed FOSS is more scalable than one-off solutions and can grow with the power of the FOSS community.
 -   **Visibility** - When we release FOSS, our developers, CivicActions and our clients get positive representation as being technology leaders and contributors.
 

practice-areas/engineering/drupal/drupal-contrib-first-module-development.md

@@ -1,16 +1,15 @@
 ## Drupal Contrib First module developement
 
-
 When a new module is needed we try to follow [Contrib First](../../../common-practices-tools/contribution/contrib-first.md), the process looks like this:
 
 1. Check with project leadership to make sure the contract allows for it.
 2. Gather requirements and identify MVP vs nice-to-haves
 3. Search for existing modules that might solve the problem. (It might be easier to stretch an existing module than build a new one)
 4. If opting to build a new module:
-   -   Choose a meaningful search engine friendly module name. (crowd sourcing name suggestions is recommended)
-   -   Create the Drupal project on Drupal.org
-   -   Populate the project page with a description of what is coming. List supporters as CivicActions and the client [directions](./README.md#contribution-to-drupalorg-modules-and-themes). If the client does not have a drupal.org page, get help from your PM to encourage them to create one.
-5. Populate the issue queue on the Drupal project with "Feature requests".  Keep them as atomic as possible. Mark any that are part of the MVP as "major". Create issues for any improvement ideas that pop up. They don't all have to be acted on, but they help shape the road map for where you want the module to go.
+    - Choose a meaningful search engine friendly module name. (crowd sourcing name suggestions is recommended)
+    - Create the Drupal project on Drupal.org
+    - Populate the project page with a description of what is coming. List supporters as CivicActions and the client [directions](./README.md#contribution-to-drupalorg-modules-and-themes). If the client does not have a drupal.org page, get help from your PM to encourage them to create one.
+5. Populate the issue queue on the Drupal project with "Feature requests". Keep them as atomic as possible. Mark any that are part of the MVP as "major". Create issues for any improvement ideas that pop up. They don't all have to be acted on, but they help shape the road map for where you want the module to go.
 6. Close the issues as you go and be sure to credit yourself, CivicActions, and the client.
 7. Begin with alpha releases. Ideally when all your MVP/major issues are closed, you are ready for the official release.
 8. After the official release, opt in to security coverage.

practice-areas/engineering/drupal/drupal-developer-tips-for-getting-the-most-out-of-open-source.md

@@ -20,7 +20,7 @@ Before wading into coding, it's important to take a good hard look at what's out
         -   **Existing patch** Search the drupal.org issue queue for issues similar to yours. Does a patch exist that you could use, test, improve, and review? If so, do so.
         -   **New patch(es)** If not, produce a patch or patches on the module to achieve the changes as [Contrib First](../../../common-practices-tools/contribution/contrib-first.md). Contribute the patch to a new or existing issue with ample explanation.
 
-    -   **New contrib module** If there is no existing module to cover the need, consider a small, focused new module for contributing back on drupal.org  as [Contrib First](../../../common-practices-tools/contribution/contrib-first.md). See [guidance on building a module as Contrib First](./drupal-contrib-first-module-development.md).
+    -   **New contrib module** If there is no existing module to cover the need, consider a small, focused new module for contributing back on drupal.org as [Contrib First](../../../common-practices-tools/contribution/contrib-first.md). See [guidance on building a module as Contrib First](./drupal-contrib-first-module-development.md).
     -   **New contrib module set** In cases where the problem is large, avoid producing a large, monolithic module that does a lot of distinct things. Instead, break the work into small distinct modules, not necessarily packaged in the same project. Wherever possible, rely on existing well coded API modules as components of your solution.
 
 -   **Theme modifications** Is it a presentation-type change? Consider implementing at the theme level. However, avoid introducing new logic or functionality at the theme level. The following should be avoided wherever possible at the theme level:
@@ -34,7 +34,7 @@ In summary:
 -   When it's necessary to build anew, focus first on doing so to a high, generic, contributed standard.
 -   Try to produce custom (site-specific closed source) modules only when the needs are limited in scope and truly specific to the site.
 -   Try to save the theme layer for what it's intended for--final presentation, look and feel.
--   When we work on a FOSS contribution for a client(s), all of the work should be billable to that client.  In the event we are doing maintenance on a contribution for no particular client, then that work can be declared as community participation (PRODEV_COMPART ->Community Participation). You will need to ask in Slack #unanet to be added to your options.
+-   When we work on a FOSS contribution for a client(s), all of the work should be billable to that client. In the event we are doing maintenance on a contribution for no particular client, then that work can be declared as community participation (PRODEV_COMPART ->Community Participation). You will need to ask in Slack #unanet to be added to your options.
 
 ## Patching vs. hacking vs. forking