Contribution and Client Projects

Contribution and Client Projects Part I: Getting started

This article is aimed at the stakeholders of a project. The second one from this series will focus on the technical aspect of contributing to Drupal in this context, and thus will be more developer oriented.

The WHY


The Developer Perspective
I will cite my colleague Blaize here: This is not simply about developing your taste, or reading code, but learning about the collaborative nature of programming. Contributing is the perfect opportunity to apply some inherent collaboration principles. Mentoring and pair programming enables your team to share knowledge and skills, cultivates mutual respect and ultimately improves the quality of the codebase and the documentation.

The Client / PM Perspective
Among other benefits, generalizing the components of a client project for Open Source can lower costs and technical debt and favours a clear and well-documented maintenance flow. Generalizing these components enforces modularity and documentation and thus offers flexibility while working with several teams or onboarding new team members. Gathering feedback from a broader user group helps to identify earlier new use cases and edge cases.

The Community
The Drupal ecosystem is powered and diversified by contributions, so encourage your team to join community initiatives and promote the company expertise.

The HOW


Identify Opportunities
Here is an excerpt from our internal documentation that summarises pretty well the leading theme that drives our development team:

Maximize open source: Lower initial costs, technical debt and maintenance costs by using and contributing to open source code as much as possible. For every feature required by a project that is not solvable by configuration or theming, try to find a generic solution that can be contributed (...)

Set the Contribution Scope


Extend an existing Drupal project
Contributions should improve the ecosystem by checking if existing solutions are already matching a use case. Extending an existing project can be achieved by:

  • Porting a project to Drupal 8
    
The required solution could exist for a previous version of Drupal. The Drupal 8 Contrib Porting Kanban can be used to get an idea of the remaining tasks. 

  • Creating a patch or a submodule

    An existing contributed project could meet, let’s say, 90% of your use case. The 10% left can be covered with a patch then contributed back.

  • Writing unit tests

    If the contributed project is critical for your use case, widening the test coverage might be a good way to ensure that every feature is working properly.

  • Making a project Drupal 9 ready

    Help to remove deprecations for Drupal 9 compatibility.


Create a New Project
The initial development of a generic solution can cost more (time/budget-wise), averaging between 2 or 3 times more. So before starting, here are a few points that could be considered. Does it implement a generic feature? Can the exceptions be configurable? Can this set of features be shared between projects? If they can be deployed in at least 2 or 3 projects as is, that is probably a good indicator.

Can the feature be isolated into a generic (packagist) library or reuse a generic library? This is often the case for third-party libraries like APIs. Is the initial release feature complete or does it allow progressive enhancements? It will give a hint about the needed maintenance time. Can it be maintained by the company that develops it? Does it fit internal or community feedback/contribution?

Integration to the Company Culture


Defining a development workflow will save you time
As a first evaluation, if it’s uncertain that the project will be reused, choose a generic name (not client specific) so it could be shared at a later stage without modifying the codebase. Use an easy-to-grasp name, one that reflects a single responsibility. If the project is doing too many things, it could be divided into several projects or submodules. 

Create a readme to allow quick developer onboarding. Move it as a standalone repository (GitHub, GitLab, Drupal.org, ...) and require it via Composer. If possible, split the generic features into packagist libraries and wrap them into your Drupal project.

If you are using untagged branches (e.g. a unique dev branch) set a commit hash via Composer to be sure that you are using the right version in your client project. Make your project discoverable internally, also to non-developers. Especially when there are several teams, so it will favour cross-project management. Make it public by creating a Drupal.org release and discoverable externally: document it, share it on social media, write a blog post.

Developer Onboarding and Documentation
If the project is released on Drupal.org, make sure that your team is familiar with the contribution processes like semantic versioning, maintenance, release and external contribution policy, and the code of conduct.

Add your team members as project maintainers and remote contribution tools: like how to do patches and interdiffs, apply coding standards (phpcs / phpcbf), write unit tests, …

The sprint participant cards could be a great way to gamify your internal contribution sprints.

Sprint participant cards

Open up your project to an internal/external contribution by making sure everybody can start quickly. Create or update the readme file and project documentation (site builder and developer) and set a clear roadmap by creating task issues on Drupal.org so the goals and current status are clear. Use the issue template summary and compare other related modules on the project page.

Resources

In our next article, we will give a brief introduction to the following points:

  • Work on the Drupal.org issue queue: create patches, re-rolls and reviews

  • Publish a project on Drupal.org and be prepared for Drupal 9