Fix duplicate heading.

common-practices-tools/README.md

@@ -6,7 +6,7 @@ title: Common practices and tools
 
 As part of our [CivicActions culture](../about-civicactions/culture.md), we share a set of practices and tools to be effective communicators, team members [working in Agile](agile/README.md), and managers of client work and company administration.
 
-As good stewards of Free and Open Source Software (FOSS) we practice a [Contribute First](contribution/contrib-first.md) approach.
+As good caretakers of Free and Open Source Software (FOSS) we practice a [Contribute First](contribution/contrib-first.md) approach.
 
 Underpinning our chosen technology stack is a [required security awareness process](security/README.md) that gets everyone set up to work online safely and avoid the scourge of [phishing](security/README.md#phishing-and-social-engineering).
 

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

@@ -9,13 +9,13 @@ Whenever we are building something that could be of use by more than one project
 ## Rationale for contrib first
 
 -   **Fiscal responsibility** - Building it and contributing it means that other government agencies will never have to pay to build the same thing twice. This helps agencies comply with Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software [OMB Memorandum M-16-21](https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2016/m_16_21.pdf)
--   **Reusability** - CivicActions other clients  and the public at large can benefit from work that was already done.
--   **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.  It is made more secure by getting more eyes on the code and more users surfacing any issues.
+-   **Reusability** - CivicActions other clients and the public at large can benefit from work that was already done.
+-   **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. It is made more secure by getting more eyes on the code and more users surfacing any issues.
 -   **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.
 -   **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, CivicAction, our developers and our clients get positive representation as technology leaders and contributors.
+-   **Visibility** - CivicActions, our developers and clients earn positive representation as technology leaders and contributors.
 
 ## Examples of FOSS CivicActions built as Contrib First
 
@@ -24,7 +24,7 @@ Whenever we are building something that could be of use by more than one project
 -   [Codit: Menu Tools](https://www.drupal.org/project/codit_menu_tools)
 -   [Content Model & Site Documentation](https://www.drupal.org/project/content_model_documentation)
 -   [Drupal Knowledge Archive Network (DKAN Open Data Portal)](https://github.com/GetDKAN/dkan)
-    - [CMSDS Open Data Components](https://github.com/GetDKAN/cmsds-open-data-components)
+    -   [CMSDS Open Data Components](https://github.com/GetDKAN/cmsds-open-data-components)
 -   [Drydock Cloud](https://github.com/drydockcloud)
 -   [Entity Field Fetch field](https://www.drupal.org/project/entity_field_fetch)
 -   [GovDelivery Bulletins](https://www.drupal.org/project/govdelivery_bulletins)

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

@@ -2,19 +2,20 @@
 title: Drupal Contrib First module development
 ---
 
-## Drupal Contrib First module development
+# 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 code-block-style -->
     - 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.
+<!--lint enable list-item-content-indent code-block-style -->
+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).

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

@@ -6,7 +6,7 @@ title: Drupal developer tips to get the most out of open source
 
 Note: _This was originally a blog post on the CivicActions site authored by [Nedjo Rogers](https://nedjo.ca/) ([d.o](https://www.drupal.org/u/nedjo)) on November 19, 2008._
 
-I [recently suggested](../drupal/most-important-decision-in-developing-a-drupal-site-contributed-vs-custom-development.md) that the way we approach new development is the most important factor in determining the long term value of our work. But just how can developers using Drupal make the most of open source by ensuring that participating and contributing is an essential part of our daily workflow? Here are some practical tips that come out of our experience at CivicActions and that can guide you in deciding how to approach new development to get the full benefit of open source. Read on as well for a discussion of patching vs. hacking vs. forking and of how to get attention for your patches.
+I [recently suggested](../drupal/most-important-decision-in-developing-a-drupal-site-contributed-vs-custom-development.md) that the way we approach new development is the most important factor in determining the long term value of our work. But how can developers using Drupal make the most of open source by ensuring that participating and contributing is an essential part of our daily workflow? Here are some practical tips that come out of our experience at CivicActions and that can guide you in deciding how to approach new development to get the full benefit of open source. Read on as well for a discussion of patching vs. hacking vs. forking and of how to get attention for your patches.
 
 ## Approach to new development
 
@@ -42,7 +42,7 @@ Changes we might make to existing modules fall into three general categories, wh
 
 -   **Patches** A patch is a contribution to a project that can reasonably be expected to be accepted. A patch is generic (not specific to a particular site). It's contributed back to the codebase with the confidence that in all likelihood it will be accepted. Thus, a patch is a short-term change--once it is accepted, the codebase will again be clean.
 -   **Hacks** A hack is a small change made to a file or files in the knowledge that it is unlikely to be accepted as a contribution to the original project. A hack may be made e.g. to provide customizations required by a client. Hacks may e.g. cause code conflicts when code is updated to a new version. Hacks have permanent costs--they must be maintained in perpetuity.
--   **Forks** A fork is extensive customizations made to an existing project to the extent that the codebase is now fundamentally customized. A fork basically converts an existing project into a custom module that must be permanently maintained on a custom basis for the site in question. Forking implies major long term costs and largely undermines the benefits of open source development, e.g., minimization of future maintenance and upgrade costs. Forks should be avoided whenever possible.
+-   **Forks** A fork is extensive customizations made to an existing project to the extent that the codebase is now fundamentally customized. A fork converts an existing project into a custom module that must be permanently maintained on a custom basis for the site in question. Forking implies major long term costs and largely undermines the benefits of open source development, e.g., minimization of future maintenance and upgrade costs. Forks should be avoided whenever possible.
 
 In weighing potential changes, it's essential to figure out what kind of change we're making and to carefully weigh costs and benefits, ensuring that the client too is aware of long term implications. At every stage, we should ask:
 
@@ -58,7 +58,7 @@ Getting patches accepted and applied takes a lot of time and effort. But it's ti
 
 -   **Make your changes generic** Avoid site-specific hacks wherever possible. Do this e.g. through adding configuration options.
 -   **Work with the current development branch** Active development on a particular module may have passed on from the Drupal version your site is in. If so, take the time to convert your patch to the active development version. If you can get it applied there, you might be able to backport it. Even if a backport doesn't get applied, you're still doing well. When the site you're working on is upgraded in future, there'll be one less patch to worry about.
--   **Break up patches** When submitting patches, it's essential that you break them up into logically distinct issues. Yes, it's a lot more work. Yes, it's tempting to just roll a single patch for the various changes you might make to a module--new features, bug fixes, etc. But doing so will often sink any chance you have of getting the patch applied. How to do this in practice? Say you maintain an SVN repository of the site you're working on, as many Drupal development shops do.
+-   **Break up patches** When submitting patches, it's essential that you break them up into logically distinct issues. Yes, it's a lot more work. Yes, it's tempting to only roll a single patch for the various changes you might make to a module--new features, bug fixes, etc. But doing so will often sink any chance you have of getting the patch applied. How to do this in practice? Say you maintain an SVN repository of the site you're working on, as many Drupal development shops do.
     -   Maintain (outside of SVN) a clean checkout of the module in question for each issue. In that checkout, make only the changes you need for that issue. Generate a patch.
     -   In your SVN repository checkout, apply each of the patches you've generated. You end up with the cumulative total of the patches, but you're able to keep them distinct.
 -   **Communicate outside the patch queue** Connect with others in [drupal Slack](https://www.drupal.org/slack). Participate in or initiate discussions on [groups.drupal.org](https://groups.drupal.org/). Selectively and respectfully contact other developers via email to ask for feedback.
@@ -68,7 +68,7 @@ Getting patches accepted and applied takes a lot of time and effort. But it's ti
 
 ## Reaping the benefits
 
-Coding to high standards and contributing back has very tangible benefits, the type that project managers and bookkeepers can easily understand, including:
+Coding to high standards and contributing back has very tangible benefits, the type that project managers and bookkeepers can understand, including:
 
 -   Reduced upgrade and maintenance costs.
 -   Greater stability.