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

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

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

@@ -11,9 +11,9 @@ When a new module is needed we try to follow [Contrib First](../../../common-pra
 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.
+    - 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.