diff --git a/common-practices-tools/README.md b/common-practices-tools/README.md index bea16517b4..cb36f9f70c 100644 --- a/common-practices-tools/README.md +++ b/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). diff --git a/common-practices-tools/contribution/contrib-first.md b/common-practices-tools/contribution/contrib-first.md index 6cd5a3780a..c3414682d0 100644 --- a/common-practices-tools/contribution/contrib-first.md +++ b/common-practices-tools/contribution/contrib-first.md @@ -15,7 +15,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, 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 diff --git a/practice-areas/engineering/drupal/drupal-contrib-first-module-development.md b/practice-areas/engineering/drupal/drupal-contrib-first-module-development.md index 88c591d59a..baa64f100f 100644 --- a/practice-areas/engineering/drupal/drupal-contrib-first-module-development.md +++ b/practice-areas/engineering/drupal/drupal-contrib-first-module-development.md @@ -15,7 +15,7 @@ When a new module is needed we try to follow [Contrib First](../../../common-pra - 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. +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). diff --git a/practice-areas/engineering/drupal/drupal-developer-tips-for-getting-the-most-out-of-open-source.md b/practice-areas/engineering/drupal/drupal-developer-tips-for-getting-the-most-out-of-open-source.md index 817b095077..352f3e3be9 100644 --- a/practice-areas/engineering/drupal/drupal-developer-tips-for-getting-the-most-out-of-open-source.md +++ b/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 @@ -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 simply 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.