Linting language changes.

CivicActions · Oct 22, 2024 · 0fb1326 · 0fb1326
1 parent 960396e
commit 0fb1326
Show file tree

Hide file tree

Showing 3 changed files with 5 additions and 5 deletions.
diff --git a/common-practices-tools/contribution/contrib-first.md b/common-practices-tools/contribution/contrib-first.md
@@ -11,7 +11,7 @@ Whenever we are building something that could be of use by more than one project
 -   **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, our developers, CivicActions and our clients get positive representation as being technology leaders and contributors.
+-   **Visibility** - When we release FOSS, CivicAction, our developers and our clients get positive representation as technology leaders and contributors.
 
 ## Examples of modules CivicActions built as Contrib First
 

diff --git a/practice-areas/engineering/drupal/drupal-contrib-first-module-development.md b/practice-areas/engineering/drupal/drupal-contrib-first-module-development.md
@@ -7,9 +7,9 @@ When a new module is needed we try to follow [Contrib First](../../../common-pra
 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.
+    -  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.

diff --git a/...neering/drupal/drupal-developer-tips-for-getting-the-most-out-of-open-source.md b/...neering/drupal/drupal-developer-tips-for-getting-the-most-out-of-open-source.md
@@ -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.  When doing maintenance on a contribution for no particular client, that work should be reccorded as community participation (PRODEV_COMPART ->Community Participation). You will need to ask to be added to your options in Slack #unanet.
 
 ## Patching vs. hacking vs. forking