[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

@@ -6,16 +6,16 @@ title: Drupal Contrib First module development
 
 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:
-<!--lint disable list-item-content-indent-->
-    - 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.
-<!--lint enable list-item-content-indent-->
-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 emerge. 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 [Drupal security coverage](https://www.drupal.org/drupal-security-team/security-advisory-process-and-permissions-policy).
+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:
+    <!--lint disable list-item-content-indent-->
+        - 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.
+    <!--lint enable list-item-content-indent-->
+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 emerge. 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 [Drupal security coverage](https://www.drupal.org/drupal-security-team/security-advisory-process-and-permissions-policy).