Mar 23 2020
Mar 23

In my previous blog post about a few of my favorite Webform things, I expressed my appreciation for the fact that that "most of the code within the Webform module is reusable and extendable." Writing that blog post helped me re-organize and improve my presentation titled, Webforms for Everyone. While updating my presentation, I found explaining and showing how the Webform module’s APIs are reusable is very challenging. As the Webform module has grown and gotten more complicated, I have continually improved the examples and demos included in the module. These examples have helped developers understand how to extend the Webform module. As a result, I decided the best way to show how the Webform module's APIs - specifically form elements and behaviors - are reusable, was to create an example.

The Webform Custom (Configuration) Form example

The goal of the Webform Custom (Configuration) Form example is to show how to leverage Webform APIs outside of the Webform module. For instance, webform elements can be used within a Drupal configuration forms. A very basic reusable enhancement is attaching the Webform module’s JavaScript to warn users about unsaved changes.

A more advanced example is reusing the Webform module's multiple element widget to collect rich data. Recently, I had to create an arbitrary list of node ids stored within a configuration file. In doing so, I was able to use Drupal’s entity autocomplete element combined with the Webform module’s multiple element support.

The below example shows how to use a multiple entity autocomplete element with the unsaved changes behavior within a configuration form.

Webform Form API example

Webform Form API example

The above example was created using the below code snippet.

Using a code generator to create examples

Code generators like Drupal Console are incredibly valuable for creating boilerplate code, particularly for complex APIs or concepts. Drupal Console can also create an entire skeleton of a custom module, which inspired me add a code generator to the Webform Devel module. The Webform Devel module's code generator shows how to convert a Webform to Form API form.

The Webform Devel module, included with the Webform core module, now adds a 'Form API' tab within the configuration 'Export' tab. The 'Form API' tab includes all the boilerplate code required to take a Webform and convert it to a custom configuration form. The generated code consists of the form class definition, route definition, default configuration, and even the custom module's info file. All of the example code can be downloaded as a zipped archive, which can then be installed on any Drupal 8 website.

The below screencast recaps some of the examples discussed and illustrates the workflow and concept behind exporting and converting a Webform into a custom Drupal configuration form.

Something about this feature is pretty mind-blowing. When I included the above demo at the end of my "Webforms for Everyone" presentation at DrupalCampNJ, I managed to get every multitasking developer to look up from their laptops.

I am excited about this new feature and approach because it makes our job as developers a little easier, and people's end-user experiences a little better.

I hope you have fun building out awesome Webform and then exporting them as configuration forms into a custom module.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Mar 09 2020
Mar 09

What is the future?

Our future user experience with computers is going to be significantly based on the intersection of personalization and voice assistants. Simply put, voice assistants are going to completely understand every question being asked, find the perfect personalized answer to every question, and empathetically return an appropriate response.

I have become slightly obsessed with voice assistants. In my limited free time, I am exploring both Alexa and Google Assistant. Both technologies have their strengths, weaknesses, and differences but their underlying user interaction and even their back-end code is glorified if/then statements. For example, “if” an end-user asks a question like, “What is the weather?”, “then,” the back-end code looks up the weather for the user’s current location and returns a response.

One of the key challenges for building useful voice assistant applications is conversational design. Although we all know how to have a conversation, designers and developers will need to discuss the problem and figure out the solution. A secondary challenge that I am noticing for creating engaging voice user experiences is providing the data behind the voice. Organizations are going to have to restructure their data to be more omnichannel and consumable by voice applications. For example, Mayo Clinic recently discussed how they had to rethink their editorial process to create content that is more distributable to voice channels.

As we begin to develop voice assistant applications and strive to build personalized user experience, everyone is going to come to the realization that we need to rethink how we structure, share, and consume data. If we collectively want to succeed, we need to collaborate and work together to define and implement standardized data structures.

Defining, standardizing, and structuring our data using Schema.org

The internet and modern computing exist because collectively we have become good at collaboratively creating and sharing open standards and open-source software. Schema.org is the most recent standard to emerge and the blog post excerpt below established who is behind Schema.org and why these organizations are working together.

“On June 2nd (2011) we announced a collaboration between Bing, Google and Yahoo to create and support a standard set of schemas for structured data markup on web pages. Although our companies compete in many ways, it was evident to us that collaboration in this space would be good for each search engine individually and for the industry as a whole.”

-- http://blog.schema.org/2011/07/on-june-2-nd-we-announced-collaboration.html

The homepage of Schema.org succinctly defines what is Schema.org.

“Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.”

-- https://schema.org/

Based on the popularity of Schema.org, there is little need for any further explanation or even examples because everyone is implementing it…we are just doing it wrong. “Wrong” is a very harsh and critical word, and I hesitate to ever use it. At the same time, in this context I am now required to justify its usage and illustrate the mistake that we are collectively making when thinking about Schema.org.

First off, for many existing websites and internet applications, schema is an afterthought that is being implemented on top of our existing web pages and content. Fortunately, adding schema to our web pages usually results in improved SEO and Google page ranking. If we spend the time implementing speakable schema, we can also have our content promoted in voice applications.

To address the growing need to include schema within our webpages, every enterprise CMS offers some mechanism to add schema to generated content. Drupal has a Schema Metatag module. WordPress has a Schema plugin. Adobe Experience Manager has the ability to create, add, and manage metadata schemas. Laying schema on top of our existing content architecture feels more like a workaround or band-aid to the challenge of collectively defining, standardizing, and structuring our data. Everyone is still defining their unique content architecture.

We are failing to address one of the biggest challenges in computer science... naming things

If we step back and think about it, there are many different ways to describe something as simple as an image object. For example, should the text associated with the image be called title, caption, label, or text, and then how do we want to describe the image’s URI and metadata?

Would it be possible for everyone to standardize on one canonical definition on an image object? What would happen if a content management system adopted a Schema-First approach?

A Schema-First approach

Several people have begun talking about the benefit of a well-defined schema at the very beginning of a project.

“I think it would be fantastic if most vendors would be able to use schema.org as a starting point.”

-- Using schema.org as a starting point for (headless) WCM

“What’s the solution, then? Establishing a single source of truth through the use of schema-first design can help align software development. Identifying a common goal, and establishing a source for teams and processes to align themselves with is incredibly important, and in this piece, we’ll give you the understanding, and some tools, to do exactly that.”

-- Using A Schema-First Design As Your Single Source of Truth

As we start creating decoupled, headless content management solutions, it becomes more critical that the front-end teams get the expected data in the expected format. “Communication” is the single word that best describes the overarching benefit to a Schema-First approach. The idea that our websites and applications communicate using the same data structures would make the concept “Omnichannel publishing” a thing of the past and change how we syndicate and aggregate information.

Besides “Communication” there are several secondary benefits worth highlighting and using to as arguments to stakeholders who need to understand the benefits of going Schema-First.

“Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general.”
-- https://developers.google.com/search/docs/guides/intro-structured-data

Everyone especially, site owners and marketers want to have a website with excellent SEO, which increases the website's overall Google page ranking. Schema.org’s structured data is specifically designed to help improve how search engines understand shared content. SEO is the reason most organizations have added schema to the web pages. Now, we are just taking it one step further and building web pages on top of a well-defined shared schema.


Omnichannel is a cross-channel content strategy that organizations use to improve their user experience and drive better relationships with their audience across points of contact.
-- https://en.wikipedia.org/wiki/Omnichannel

COPE (Create, Once, Publish, Everywhere) approach to content management, which has been rebranded as “Omnichannel,” has helped people understand the importance of creating and distributing content. COPE and Omnichannel is still focused on an organization reaching users across an organization’s contact points. A Schema-First approach would make the “everywhere” in COPE mean “everyone”. Everyone inside and outside an organization would be able to share and consume data.

Syndication & Aggregation

Any organization that has implemented schema on their web content has seen the benefit of their content - that it is more accessible within search results and voice applications. It’s very hard for people to conceptualize what it would be like if websites and applications could seamlessly push and pull data from one website to another. It is hard to imagine that every single webpage with biographical or location information could have the data structured in the same way.

Even though we are creating API First Content Management Systems, it still requires developers to document the data being syndicated, and the developer aggregating this data needs to understand, transform, and consume the data. It pains me to admit that many organizations’ internal teams still struggle with sharing and consuming data.

Shouldn’t an organization press release be automatically consumable by any application?

An amazing proof-of-concept would be Schema-First CMS being able to pull in any NewsArticle from a website, like The New York Times, which implements Schema.org for their articles. A content manager should be able to cut and paste a URI, and with absolutely no code to normalize or massage the data, the external content should be available with the CMS.


“Now, one thing that schema.org won’t do for you is map to your product strategy, content strategy or layout.”

-- https://markdemeny.com/2019/09/using-schema-org-as-a-starting-point-for-headless-wcm/

A Schema-First approach is not a solution but provides a rock-solid foundation for building out an organization’s digital strategy and user experience. We also have to recognize that Schema.org is continually evolving, improving, and even deprecating some entities and properties. Fortunately, as one of my next steps, I want to explore prototyping a Schema-First Content Hub/Repository using Drupal, which as a community in their upgrade from Drupal 8 Drupal 9, is learning how to evolve and properly deprecate code and data structures.

Next steps

Analyze, Prototype, Evangelize

The concept of taking a Schema-First approach to the Information Architecture behind a Content Management System is not going to be difficult to sell; the challenge is going to be implementing it successfully.

Schema.org is an evolving standard, and its shortcomings need to be analyzed and discussed. Examining how we are transforming our legacy content structures to conform to Schema.org’s specifications could show us what is missing from Schema.org’s specifications. We also need to determine what data should and should not be modeled via schema. For example, we should also think about how to manage presentation information and where it should live.

I am more of an implementation person and not necessarily a specification person. Everyone has their strengths and weaknesses. This is why I frequently use the word collaboration throughout my blog posts, to encourage everyone to contribute. The best feedback which I am going to be able to provide is going to come from implementing and prototyping a Schema-First content management solution. Fortunately, there are people like Peter F. Patel-Schneider at Nuance Communications, Inc. analyzing Schema.org (Article - Video),

Of course, I am guiltily optimistic in thinking that Drupal and its community can solve any problem. At the very least, Drupal is the open-source leader for enterprise content management and user experiences. And fortunately, I am not alone in thinking that Drupal could be a forerunner for a Schema-First CMS.

“So that’s why I’ve been thinking about how it would be if we just had one CMS which would, obviously, be perfect. The perfect CMS, or PCMS, for short...PCMS doesn’t exist, but many of the concepts mentioned in this article do. Drupal has something called the Content Construction Kit which brings ‘custom fields’ to a new level.”
-- A proposal for a perfect CMS

For me, I want to follow up this post with a proposal on how we can prototype a Schema-First implementation of a decoupled Drupal application, or maybe even more specifically, a “Content Hub/Repository.”


For open source and open standards to succeed, we collectively need to evangelize our thoughts and ideas. I know some organizations have invested time and resources in building better content models based on Schema.org. Organizations need to share their experience and get involved by encouraging clients to use and improve these standards.

For now, when your organization is layering Schema.org on top of your existing websites you should think about the possibility of a single way for everyone to organize, structure, and share data because I believe there is one, and Schema.org might be the solution.

Feb 10 2020
Feb 10


To perform A/B testing, segmentation, and the personalization of a webform, a site builder needs to create a variant of the form that can be triggered based on certain contexts, which can be as simple as a custom URL.

A variant is a form or version of something that differs in some respect from other forms of the same thing or from a standard.

-- https://www.lexico.com/en/definition/variant

A webform variant might alter a form's labels, descriptions, and even its confirmation page. A webform variant could be used to create an A/B test to confirm if a tweak or improvement to a form's user experience increases the rate at which the user completes a form. A basic A/B test would randomly load two variants, allow a defined number of users to complete the form, and then review the results to determine which variant had the highest completion rate. The most successful variant can then be permanently applied to the webform.

A webform variant can also be used to create a personalized webform based on a user's demographics. For example, webform's available inputs, labels, and even options could be altered based on a user's gender, age, locale, employer, etc. Even subtle tweaks can improve a form's user experience - for example, removing inappropriate disease options or inputs based on a user's gender can simplify an appointment request form.


Right now, the one out-of-box solution is to create multiple instances of a webform and route users to the appropriate webform. The biggest issue with having multiple webforms is that, in doing so, it collects two different datasets. Ideally, all submission data should go into the same results table to be analyzed with just the user experience changing. You can also use conditional logic to tweak hide/show elements and disable/enable certain behaviors.

Both approaches have limitations and lack some organization. For A/B testing, it is possible to alter a form via JavaScript. Still, this approach is limited to front-end tweaks - for example, you can't change an element's server-side conditional logic using client-side JavaScript.

The best solution is to provide an administrative user interface for defining and managing webform variants.


Variant definition (element)

Variant definition (element)

Variant definition (element)

Site builders need to define a variant type using an element. Once a variant element is added to a webform, a dedicated "Variants" tab is then displayed in the form’s management tabs. The "Variants" tab is used to create and manage variants of a webform.

Storing the variant definition in a variant element makes it easy to track and report submissions by variant. By default, the variant element is not displayed on the form or submission. Also, by default, a variant element is allowed to be prepopulated using a query string parameter. Using a query string parameter to set the variant makes it very easy to track completion rates by examining page views by URL. A variant can also be set using the element's default value or a webform field's default data.

When prepopulation is enabled, a site builder can choose to enable A/B testing by checking the randomize property. When randomize is checked, visitors are randomly redirected via JavaScript to an enabled variant.

Variant instances (plugin)

Variant instances (plugin)

Variant instances (plugin)

Once a variant element is placed on a form, variant instances need to be added to a webform. Variant plugins work very similar to webform handlers. A variant plugin can alter any aspect of the webform.

The default webform variant plugin that ships with the Webform module is called the 'Override' plugin. This plugin allows site builders to alter elements, settings, and behaviors using YAML.

Altering settings

Using the 'Override' plugin, site builders can alter a webform's form, submission, and confirmation settings and behaviors. For example, a variant can change a webform's confirmation type and message. It is also possible to setup variant-specific submission limits.

Altering elements

Altering a webform's elements makes it possible to change an element's types, label, validation, and even conditional logic. Elements can also be hidden or displayed in a variant. In YAML, a site builder enters the element name and element properties that need to be altered. For example, using a variant, a select menu can be changed to radio buttons.

Altering handlers

Altering a webform's handlers configuration is mostly applicable to email handlers because a variant can alter an email's subject, message, and recipients.

Custom Variant Plugins

Custom Variant Plugins

Custom Variant Plugins

The 'Override' variant plugin is very flexible and makes it very easy to create A/B tests. For webform segmentation, where multiple similar variants are needed, a developer might want to implement a custom variant plugin, which provides a dedicated configuration form and custom business logic to apply the variant.

Managing variants

Variants are very similar to Handlers, with the sole purpose of variants being to alter a webform. Variants are managed using the same user interface as Handlers with the addition of "View", "Test", and "Apply" operations. The "View" and "Test" operations allow site builders to review the variant's changes and test that submission handling is working as expected.

Applying variants

Applying variants

Applying variants

The "Apply" operation allows a site builder to apply a webform variant to the master webform. As a variant is applied, the selected variant or all variants can be deleted. The “Apply” operation is used to finalize an A/B test by applying the winner.

Webform nodes

Webform nodes

Webform nodes

Since variants are defined as elements types, they can be populated using a webform field's default data. When a webform has variants, the “References” tab, which tracks all webform nodes, will now display the variant information for each webform node. An “Add reference” button is placed at the top of the page. The “Add reference” button opens a dialog where site builders can select the variant type when creating a webform node.

Placing variant instances in individual webform nodes makes it easy to create segmented dedicated webforms that still route data to the same submission table. For example, an event node can use a shared registration form while using variants to change the form based on the event type.

The concept and use case for variants is relatively complex, and it helps to see variants in action. There is a Webform Example Variant module, which includes an example of an A/B test and an example of a segmented webform. The “Example: Variant: Segments” webform demonstrates how a webform can leverage multiple variants to create and a long- and short- form for multiple organizations using a custom WebformVariants plugin.

The below screencast walks-through what are webform variants and how can variants be used to create A/B tests and segmentation.

What is next?

Experiment, Experiment, Experiment

The single-word to describe why I felt it was essential to add variant support to the Webform module is "Experimentation." As a community, being continuously open to new ideas and experimentation is what keeps Drupal moving forward.

Variants allow sites to experiment and improve their existing webform using A/B testing. Variants open up the possibility to create segmented and targeted webform for specific user audiences. As with every aspect of Drupal and Webform, variants are extendable, which opens up the possibility that external personalization services can be connected to the backend of a webform to create personalized and individualized webform experiences.

I look forward to seeing what people can accomplish using variants. And at the very least, we can perform A/B tests and build more awesome webforms.

Who sponsored this feature?

Memorial Sloan Kettering Cancer Center (MSKCC) has been my primary client for the past 20 years. Without MSKCC's commitment to Drupal and their early adoption of Drupal 8, I would most likely not be maintaining the Webform for Drupal 8. Most of my work on the Webform module is done during my free time. Occasionally, MSKCC will need a Webform-related enhancement that can be done using billable hours. In the case of adding support for variants, MSKCC, like most healthcare systems, need webforms that target multiple and segmented audiences. Being able to create variants makes it easier for MSKCC to manage and track segmented forms and submissions.

I am very fortunate to have an ongoing relationship with an institution like MSKCC. MSKCC appreciates the value that Drupal provides, and the work that I am doing within the Drupal community.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Jan 21 2020
Jan 21

Every new year, aside from maintaining and continually improving the Webform module for Drupal 8, I look forward to putting together and practicing a Webform presentation with the hope that it will be accepted at the upcoming DrupalCon.

My first Webform presentation, a general introduction to the Webform module for Drupal 8 at DrupalCon Baltimore, was simply titled Webform 8.x-5.x.. The following year at DrupalCon Nashville, I organized a more feature-focused presentation called Webform: There is this for that. Last year at DrupalCon Seattle, I did an ambitious 90-minute Advanced Webform session.

Each year, I have to decide what is the best approach to organizing and sharing the Webform module at DrupalCamps and DrupalCon. I struggle with including too much or too little information in my presentation. It’s also difficult to pinpoint my target audience - every DrupalCon session is supposed to have a target audience, but I want everyone to use and appreciate the Webform module. And while I certainly appreciate the event’s organizers need to classify things, I really believe in letting anyone who attends DrupalCon know that the Webform module isn’t specific to any one group.

The target audience for the Webform module is everyone.

Webforms for Everyone

The defacto audience for the Webform module is developers, only because I am continually scratching my developer itch when adding new features and improving APIs. At the same time, I am always thinking about site builders, who on a daily basis need to build and manage forms. Finally, it is hard to forget about the business owner and the end-users because, ultimately, we want to create an engaging user experience for end-users that meets a business owner's needs.

So after last year's developer-focused presentation, I started organizing a presentation titled "Webform for Everyone." I recently presented (aka practiced) this presentation at NEDCamp, and honestly, my presentation went so-so. Keeping certain information too basic, started to bore developers. Conversely, showing code samples, lost half the audience. I have done enough presentations not to be discouraged, but realized that I need to rethink my approach.

The best advice I got while practicing my "Advanced Webform" presentation was to focus on the most exciting and essential aspects of the Webform module. In other words, talk about my favorite Webform things.

My favorite Webform things

The "Webforms for Everyone" presentation is still going to broadly walk-thru the three primary audiences for the Webform module, which are site owners, site builders, and developers. I’m aiming to engage everyone and focus on "my favorite webform things" as they relate to each audience group. I admit that I am struggling with my slides. As such, I thought the best way to reapproach this challenge would involve stepping back and writing this blog post, about "my favorite webform things"

10 - YAML Source

Use the YAML source...

The Webform module started as the YAML Form module, which allowed people to build forms by writing YAML markup. At some point, the YAML Form module started to have UI and became the Webform module for Drupal 8. Please read Webform 8.x-5.x: Where Do We Come From? What Are We? Where Are We Going? to learn more about this journey.

Every Webform demo I have ever given includes showing people the YAML source editor because it demonstrates how Drupal's Form API (FAPI) render arrays are used to build forms. Being able to see an entire form's elements on one page makes it easier to tweak a form's labels and descriptions. Developers, including myself, can also hand-code webforms. I enjoy being able to take something as complex as a form and represent it using something as simple as YAML.

YAML Source

YAML Source

9 - Results

The results tab provides a quick and straightforward way to view submissions.

The Webform's use-case is "build a form", "collect submission data", and "distribute submission data". Collecting data requires that it is also easy to review. Drupal core's Views module is an incredible tool for building reports, but it requires a full understanding of Drupal's Field API. Most non-technical users simply need to be able to filter and sort submissions and then hide or show a few columns. With this in mind, the Webform module provides a very straightforward way to customize the results table.

Of course, developers and advanced site builders can replace the Webform's default results table with a custom view. Here is a video showing how to customize and improve the Webform module's Views Integration.

I enjoy keeping things as straightforward as possible while offering the most flexibility, and my attempts to simultaneously provide both of these qualities has been a constant tug-of-war while developing the Webform module.



8 - PDF generation

PDF makes it easy to print or save a submission

Just as important as viewing submissions online, it’s equally important to be able to download submissions. PDFs provide a universal and straightforward way to share information. Being able to generate and download a PDF for single or multiple submissions provides the most visually appealing and standardized approach to share information.

What I like most about the Webform modules's PDF generation is being able to leverage the Entity Print module to provide comprehensive integration. Webform modules PDF support is a great example of Drupal’s extensibility and community working together. 

7 - External Libraries & Add-ons

Like PDF generation, many of the coolest aspects of the Webform module are provided by external libraries and add-ons. I am always in awe of what people contribute back to the Drupal and larger Open Source community.

Early on in the development of the Webform module, I started leveraging external libraries to provide advanced features like select menu enhancements and a signature element.

Now the Drupal community is extending the Webform module and providing additional functionality and integrations. Contributed add-on modules have handled several key aspects of the Webform module including Views integration.

External Libraries & Add-ons

External Libraries & Add-ons

6 - Webform Elements

Every type of element is available.

Being able to build the Webform module on top of Drupal's Form API while also leveraging external libraries made it possible to develop and maintain a wide variety of Webform elements. Webform elements, which can vary from basic HTML input to an advanced composite element, make it possible to collect any type of data.

Every possible element title and description variation is supported. For example, a form element can "hide" descriptions in help tooltips or read more slide-outs depending on the form’s use case and requirements.

The concept that every single aspect of an element is customizable can feel overwhelming and also empowering. I appreciate being able to add that little extra CSS to an element when it is needed. 

5 - Configuration and Settings

Everything and anything is customizable.

As we walk through this list, a common theme for the Webform module is everything is customizable. Every message displayed to an end-user can be changed. Even administrative features like the usage of modal dialogs can be adjusted.

I enjoy knowing that every single possible way to confirm a form submission is supported. I like being able to open a confirmation message in a simple modal dialog.

5 - Configuration and Settings

5 - Configuration and Settings

4 - Reusable code

I know it may seem strange that one of my favorite Webform things is the simple fact that most of the code within the Webform module is reusable and extendable using Drupal's plugin and entity system.

Drupal's entity system made it easy for me to create a very basic UI for managing reusable lists of options and images for select menus, checkboxes, and radios. Drupal's plugin system makes it easy for developers to create custom webform elements and handlers.

I am not sure if Drupal developers realize that any webform element, including elements like select, checkbox, and radios with the other option, entity references, composites, and multiples, can be reused in their custom forms, built with Drupal's Form API. There are even some simple utility classes available to manipulate custom-built forms, elements, options, and arrays.

Reusable code

Reusable code

3 - Twig support

Twig is awesome!

There is a limited amount of flexibility available in a graphical user interface, and sometimes the most flexibility happens when a developer can only write the code they need. The old school and utterly insecure solution was to allow developers to inject PHP into a page. Before Drupal 8, pages were rendered using PHP templates. Luckily with Drupal's adoption of Symfony, the Twig templating engine was added to core. Initially, I thought Twig was just for rendering variables and executing loops with templates. At some point, I realized that Twig supports most math calculations and even some OO concepts. It makes a lot of sense to build custom emails using Twig. It also mind-blowing that Twig can be used to perform calculations for computed elements.

Computed elements can collect and manipulate that little bit of extra data that needs to be captured and stored with a submission. Computed elements can calculate totals and even trigger custom conditional logic.

Twig support

Twig support

2 - Remote post handler

Everyone needs to be able to consume and share information.

The remote post handler allows a webform submission to be posted to a URL. When I added the remote post handler to the Webform module, I thought it was nice to have feature that would be used by a few websites. In the past few years, with the rise of CRMs, being able to push data from server to another is a requirement for most enterprise websites. I frequently recommend that people build a webform in Drupal, but remote post the submission data to a system that is designed to aggregate, analyze, and report on data securely.

Remote post handler

Remote post handler

1 - Videos

Having some adequate documentation is one of my biggest accomplishments with the Webform module. Like many developers, I do not like writing documentation. That said, documentation makes it possible for people to understand how things are supposed to work. I started out recording some general demos of the few modules that I have contributed back to the Drupal community. I realized that I could add links to videos about functionality and features within the Webform module's user experience.

It is fun and rewarding to show people the latest and greatest Webform feature or improvement. I know the Webform module can occasionally feel overwhelming, and it helps to have a video that guides someone through the process of getting the most out of the Webform module.




As you can see from this blog post, on my favorite Webform things is sharing my code, ideas, and passion with the Drupal community. Hopefully, you can catch my "Webforms for Everyone" presentation at DrupalCamp NJ, MidCamp, or DrupalCon Minneapolis.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Dec 12 2019
Dec 12

Last month, I attended Acquia Engage in New Orleans. My goal was to gain a better understanding of Acquia’s Digital Experience Platform (DXP). Personalization and marketing automation using products like Acquia Lift and Mautic are the latest trends in building ambitious digital experiences, and I think they are here to stay. One of my takeaways from Acquia Engage is personalization can make our lives better.


I see personalization having two possible impacts on digital experiences:

Personalization can try to sell more products and services to users, or it can sell a better product and provide better service.

I lean toward the latter because I’d rather have a company make it easier for me to buy the things I want, rather than a company trying to sell me something that I don’t need or want. On a side note, I am gradually becoming obsessed with Voice Assistants, like Alexa and Google, because they have to potential to make our lives easier. For example, I would love to have Alexa buy me movie tickets at my local theater in one or two voice commands. For this to happen, Alexa is going to need to have a comprehensive user profile about me, which is then used to create a personalized voice experience. We are not exactly there yet, however, soon personalized digital experiences are going to be the norm. The immediate challenge is figuring out how to get there.

Crawl, Walk, Run Methodology

Personalization is challenging to get started with, which is why everyone is using the “Crawl, Walk, Run” methodology for gettings up-to-speed with personalization. “Crawling” begins with collecting data, “Walking” starts when organizations can understand and segment their users, and finally “Running” is creating personalized, individualized user experiences. To me, the real lesson of the “Crawl, Walk, Run” methodology is its emphasis on the value of stepping back from a complex, challenging problem, figuring how to understand the problem, followed by outlining a solution, and finally implementing the solution.

The Webform module tries to solve the problem of collecting and distributing user data via forms. For personalization to work, user data needs to be collected from multiple channels and data points. Webform is one of many data points within a person’s user experience.

Webforms and Marketing

“No, the Webform module is not a marketing automation module but is one of the most vital building blocks of an integration between Drupal and other third-party marketing automation software.”

The blog post then proceeds to highlight some marketing-related modules, including a few CRMs and Mautic. Shefali’s blog post does a great job of showing what’s possible with marketing automation and recognizes that webforms are a key part of the process of connecting with users.

Webforms and Data

A form is one of the largest data points when it comes to personalization and marketing. Forms are one of the only data-points where users deliberately and intentionally share a lot of information with an organization. A well-designed and easy to complete form can collect a lot of valuable information about a site’s users. In some cases, forms are the most immediate indicator of a website’s ROI, because a user filling out a form is either a potential or actual paying customer. It is important to ensure that users can and will fill out a form.

Webforms, Testing, and Variants

Building intuitive, easy-to-use, and accessible forms is a good investment that leads to better user experiences. Building a great user experience requires an iterative process of planning, implementing, testing, and improving. The best way to confirm that an improvement or experiment is successful, is to perform an A/B test where the original and improved variant is randomly presented to end-users, and each variant’s success rate is tracked and then compared. Being able to create variants of a webform makes it easier to create A/B tests. Webforms that support variations should also be able to support personalization.

A variant is a form or version of something that differs in some respect from other forms of the same thing or from a standard.

-- https://www.lexico.com/en/definition/variant 

Webforms and Personalization

Good personalization begins with finding a common starting point and then tailoring the user’s journey. For example, a user visits your homepage and the different targeted variation of the banner changes based on the user’s demographics.

Shouldn’t forms be able to provide personalized user experiences?

The Webform module supports conditional logic, which can hide/show or require elements based on inputted and computed values. Conditional logic is limited when it comes to which aspects of a form’s user experience can be changed. For example, replacing a form’s labels, descriptions, and behaviors is not supported by conditional logic. Conceptually, personalization means any aspect of a user’s experience should be alterable as long as it provides value.

Being able to personalize a webform sounds like a daunting task, especially considering many people, including myself, are still getting comfortable with personalizing a callout on a homepage. Using the “Crawl, Walk, Run” methodology might be the best way to take on the challenge of creating a personalized webform and figure out the best approach to implementing them.

Crawling - A/B Testing

Crawling begins with collecting data and testing a hypothesis.

Personalization can only begin when user information and statistics are collected and analyzed. Most websites have some basic page views analytics setup. If, after completing a form, users are directed to a dedicated confirmation page, which is the default behavior for a webform, then form completion rates are already being tracked. Knowing if a form is completed makes it possible to perform some A/B testing.

A/B testing allows teams to start thinking about how they can improve a form’s user experience, test their theories, and collect meaningful data. Frankly, before any form personalization can begin, teams need to understand their users and provide a thought-out baseline user experience. Knowing if a website’s targeted audience is okay with long multi-step forms compared to short compact one-page forms helps designers and site builders to establish user experience guidelines and style guides.

The goal of A/B testing is to start collecting meaningful data about users and to start improving user experience by gradually testing and confirming the success of small improvements in a form. A/B testing encourages digital teams to think about the different variations of a form, which then leads to building form variants that target specific audience segments.

Walking - Segmentation

Walking starts when specific audience segments are targeted.

Instead of building form variants to A/B test a hypothesis, segmentation is creating form variants that target specific audiences. The goal is to create a tailored user experience that makes it easier for different types of users to complete a form. Segmentation could be as simple as showing and hiding form questions based on conditional logic. Advanced segmentation would entail changing the language, messaging, and tone of a form based on the current user type.

For example, on an appointment request form, changing an input’s label depending on whether someone is a patient or caregiver could make people feel more welcome. Asking for ‘Your first name’ or the ‘Patient’s first name’ is more direct than just the label ‘First name’. This might seem like a silly and nuanced change, but take this example and apply it to a form being completed using a screen reader or a voice application. We should all care about form accessibility, and one day our forms are going to have to be voice friendly. Forms are going to have to be personalized based on the current user’s information.

Another benefit of segmented forms is the submission data could be saved to the same place with the first piece of data being the user type/segment. Once we have a comprehensive user profile then we can start thinking about personalization.

Running - Personalization

Running occurs when a form is personalized to an individual user.

For me, a personalized form means a lot more than conditional logic and segmentation. A personalized form might begin with fully identifying a user and pre-filling in any known information. Form labels and descriptions might include a user’s name with appropriate pronouns. A truly personalized form’s user experience should interact and respond as a user enters information.

A personalized form is going to have to ask the right questions, in the appropriate tone and at the right time.

Voice user interfaces (VUI) are still evolving with the end goal of computers, with AI being able to engage in seamless conversations. Forms are currently one-sided, somewhat stilted conversations with a user that collects information. Personalized forms should be a flowing intelligent, even empathetic, natural, and productive conversation with a computer.

My hope is a personalized form’s user experience, possibly through a voice user interface, will result in the end-user simply feeling that they just had a pleasant conversation with a computer, which helped them get what they need. We are most likely a decade or two off from this goal; for now, we need to start crawling and walking for a few years, and then we can move on to running.

What’s next?

For any type of personalization to occur in the Webform module’s user experience, webforms are going to have to start supporting variants. Being able to create and manage variations of a webform will open up the Drupal community to performing A/B tests and building out segmented forms.

I am actively working on adding variant support to the Webform module. I will follow-up this blog post with a more technical post about how to use webform variants to create A/B tests and segmentation.

To build that impossible ‘pie-in-the-sky’ intelligent, personalized form user experience, we are going to build extensible and reusable APIs that hook into personalization engines and inspire the Drupal community to do what it does best…collaborate. As always, I can’t wait to see what we all come up with.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Dec 03 2019
Dec 03

About the Webform module

The Webform module is a form builder and submission manager for Drupal. The Webform module allows site builders to customize forms and route submissions to multiple systems, including email, remote servers, and spreadsheets.

About the Group module

The Group module allows site builders to create arbitrary collections of content and users on a site and then grant users access to these collections. The Group module allows sites to build communities and manage their organization by creating groups of users with various levels of membership.

The Webform module for Drupal 8 does not fully integrate with the Group module. In Drupal 8, webforms are configuration entities, however, the Group module currently only supports content entities. To learn more about this issue, see Issue #2856333: Webform as group content.

Webforms can be attached to nodes, which are content entities which are supported by the Group module. This approach only provides access controls to determine which group members can simply view and submit a webform. It does not provide webform submission and element level access controls.

For example, a group could have a dedicated event registration system with a dedicated registration webform. A group administrator can control who has access to the event registration webform but there is no mechanism to allow group-specific roles to view, manage, and delete event registrations.

Provide webform submission and element level access controls to webforms attached to nodes.

Existing access controls

The Webform module already provides roles, user, and permission level access controls to webforms, submissions, and elements. There is even a dedicated Webform Access module that provides webform node-specific access controls using webform specific groups. The Webform Access module is a lightweight group-based access control system for sites that don't need a full-blown Group module implementation.

Learn more about the Webform module existing access controls.

Extending access controls

The Group module includes support from group-specific roles known as 'Group roles'. 'Group roles' are similar to Drupal's out-of-box user, roles, and permissions that allow administrators to select which roles with permissions are applicable to a user. 'Group roles' are specific to members of the group. Since the Webform module already provides 'user role' access controls, it makes sense to extend this solution to support 'Group role' access controls. In other words, anywhere you can select 'user role' level access, you can now set 'Group role' level access.

'Group roles' have been added to the webform access controls and element-specific access controls.

Webform access controls

Once the Webform Group module is enabled, when you navigate to a webform's access form, you will see the 'Group (node) roles' select menu appended to every operation/permission except for configuration access. Every group type role is listed and general roles are also supported. For example, you can select the 'Member' role and all members of the current group will be automatically assigned this permission. For example, members of the current group can be allowed to edit their 'own' submissions.

The current group is determined by the currently loaded webform node's parent group relationship. Since webform submission stores the webform node as the source entity, a webform submission is also able to load the current group based on the source entity relationship. In other words, as soon as a webform node is associated with a group, the 'Group role' access controls will start being applied to the Webform node and its submissions.

Below is a screenshot of 'Group (node) roles' on the webform access form.

'Group (node) roles' on the webform access form

'Group (node) roles' on the webform access form

Element access controls

To allow groups to fully administer a webform node's submissions, it helps to provide administrative elements on a webform. Administrative elements are just webform elements with access controls. Now, you can apply 'Group role' access control and allow certain group roles to view and update administrative elements. The most common use case for administrative elements is to permit certain users/roles to add notes and reviews to a submission.

Below is a screenshot of 'Group roles' on the element edit form.

'Group roles' on the element edit form

'Group roles' on the element edit form

Email handler tokens

Webform email handlers now also include the ability to send emails to all members of a group role. For example, an email notification can be sent to all members of a group or just a few people who are assigned the 'Manager' group role. In the backend, the email handler's group roles are defined as tokens that return a comma-delimited list of email addresses.

To allow group roles to receive emails, site builders must explicitly allow each group role to be enabled and available to receive an email. This ensures that site builders understand that all group role member's email addresses will be exposed to anyone building and configuring a webform.

Email handler tokens

Email handler tokens

Some limitations and provisos

Webform Group integration is limited to webform node submission management. The recommended workflow would be for a site builder to create a shared webform that is reused by multiple groups. Each group has a dedicated webform node instance for the shared webform. The new webform group roles access controls are then used to decide which group roles (aka members) can create, update, and delete their own submission or any submissions.

To allow a group to create one-off, group-specific webforms, site builders would have to use the existing webform permission system, possibly combined with some custom code to make it easier for a created webform to be associated with a specific group.

Webform Group Demo module

Besides telling someone how a feature or module is supposed to work, it also helps to show them how the feature or module works. The Group module is a very powerful and flexible solution that requires a site builder to understand the concept of group types, roles, members, and content. Sometimes the best way to understand a module is to build out a demo that shows the baseline functionality required to address a common or specific use case.

The Webform module now includes the Webform Group Demo module, which shows how to implement webform group role access controls for a webform referenced by multiple group-specific webform nodes. The Webform Group Demo installs configuration for two group types, which are called A and B, with some group roles including member, reviewer, manager, and administrator. An install hook creates two group instances for each group type with related user accounts, members and finally webform node instances.

Webform Group Demo module

Webform Group Demo module

New access control related hooks

The Webform module includes a lot of submodules, which are all optional. Packaging and maintaining these submodules makes it easier to ensure API changes do not break any integrations. A byproduct of using submodules is occasionally we’ll find the need to improve existing APIs and add new APIs or hooks.

To improve the extendability of webform access controls the below hooks were added.

Element access hook



array &$element,

\Drupal\Core\Session\AccountInterface $account = NULL


This hook makes it possible for modules to decide when a webform element should be visible or hidden to create, update, and view operations. It is important to note that a module can also use form and element alter hooks to set an element's #access property to FALSE to hide an element.

Submission query access alter hook


\Drupal\Core\Database\Query\AlterableInterface $query,

array $webform_submission_tables


This hook allows modules to decide which submissions are visible on the results page and in a webform submission view. Altering the submission query prevents submission data from being unintentionally displayed when creating a list of submissions. Currently, only the Webform Node, Webform Access, and Webform Group implement this hook.

It is worth noting for webform and webform submission level access controls, developers should use hook_ENTITY_TYPE_access() API via hook_webform_access() and hook_webform_submsision_access().

Sponsoring a feature

The Webform Group integration was sponsored by Lutheran Church of Bavaria. The Lutheran Church of Bavaria is using Drupal 8 to build out its intranet. They are using the Groups module to build out their organization's internal subdivision workspaces, and the Webform module is being used to handle internal human resources and general requests.

If you want to sponsor a feature, please read my blog post and create a ticket in the Webform module's issue queue.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Nov 04 2019
Nov 04

The Webform module for Drupal 8 provides support for basic, advanced, and composite inputs/elements. Developers can also create custom elements and composites via code. Sometimes end-users need an interactive visual mechanism to select a complex option like a map location. The Image select element is limited to allowing users to select horizontally-aligned images.

What if an end-user needs to select a seat on a plane, a part of the human body, or a room at a conference?

HTML5 and SVG allow designers and site builders to build visually rich and interactive elements. To convert rich interactive HTML/SVG elements into a form input, there needs to be some PHP and JavaScript glue code that captures a user's selection and sets it as a webform submission value.

Besides capturing the end-users selection, the PHP and JavaScript code must also ensure that the interactive HTML/SVG element is accessible to users with disabilities.

Allow site builders to create a custom 'options' element using HTML/SVG markup.

The general concept for creating a custom 'options' element' is to allow site builders to provide HTML/SVG markup that is dynamically converted into a select-able and accessible Webform element.

Below is a straightforward example of some HTML markup that can be enhanced.

SVG support requires the same data-id and data-name attributes being added to the HTML markup. Below is an example of a single clickable element in SVG.


The HTML/SVG markup must provide an option value or text attribute that can be used to create a list of available options. The default recommended 'value' attribute names are 'data-option-value', 'data-value', 'data-id', or 'id'. The default recommended 'text' attribute names are 'data-option-text', 'data-text', 'data-name', 'name', or 'title'. The Webform module uses these value/text attribute names to parse and detect the custom element's available options.


Once the available options are detected, JavaScript is used to make each option focusable, clickable, and accessible using ARIA (Accessible Rich Internet Applications) and related HTML attributes. To allow the user's select option to post back to the server, a select menu is provided to capture the user's selection. The select menu supports HTML5 validation and provides a fully accessible alternative input for a user using a screen reader.

Here is an example of a clickable map of U.S. states.

Clickable U.S. States

Clickable U.S. States

More about custom 'options' elements

Only webform administrators can define custom 'options' elements. Since these elements support any HTML/SVG markup, including JavaScript; Only trusted users should be allowed to administer the Webform module and create custom 'options' elements. 

HTML/SVG markup can be loaded from a URL or cut-and-pasted into the code editor. HTML/SVG markup supports Twig which can be used to enhance the markup and even render custom options.

To being building custom 'options' elements, install the Webform Custom Options module (/admin/modules) and go to the Custom options configuration page (/admin/structure/webform/config/options_custom/manage).

Custom options configuration page

Custom options configuration page


Besides parsing option value and text from the HTML/SVG markup, the option value, text, and description can also be provided via the element edit form. Options entered via the element edit form are available for translation.


To make it easier for end-users to see more information about the available options, tooltip support is provided. SVG graphics can be panned and zoomed using the SVG Pan & Zoom library.


Custom 'options' elements are available to webforms as simple elements and entity references. Custom 'options' element which support entity references must have their option value match the entity reference ids, or the option text match the entity reference titles.

What is next for custom 'options' elements?

The Webform Custom Options module is experimental. If you extend, alter, or override any code, please test your changes when updating the Webform module. The module's code still needs to be finalized. We also need to determine if any additional hooks or templates are required.

Currently, the only example is a map of U.S. states. More HTML/SVG examples and possibly a dedicated 'Webform Custom Options Examples' module are needed. A dedicated contrib module which provides SVG maps is also something that would be great to have. All examples need to use freely available SVGs with proper attribution to the source.

As a community, we need to explore what is and isn't possible using HTML and SVG graphics when creating a custom 'options' element.


Documentation always needs improvement. Solving the challenge of click-able custom options requires a fairly complex solution. Please help me clarify how things work and how to create the necessary custom HTML/SVG markup.


Accessibility should never be ignored, assumed, or taken for granted. Custom 'options' elements need to be fully keyboard accessible and provide the right information to screen readers. The SVG Pan & Zoom library does need some accessibility improvements, especially around keyboard navigation.

Who sponsored this feature?

Two years ago, Madhan K'Samy (MkSamy) created Issue #2907663: SVG image parts as selectable options element, and we discussed this feature. I was able to build a simple prototype. Madhan K'Samy was unable to sponsor this feature. However, for the past two years when people asked for similar functionality I would demo the prototype.

Steve Babbitt from Mile3 (https://www.mile3.com/) approached me about sponsoring the new Webform Options Limit submodule, mentioning that his client needed a clickable SVG graphic. I showed him the prototype and he spoke with his client, who was willing to sponsor and contribute this feature, which allowed us to scope out the feature request using Issue #3081795: Allow custom HTML/SVG markup to be used as options.

Steve and clients have sponsored and contributed a feature that has changed what is possible using the Webform module. This feature allows an airline to convert an airplane's seating chart into an SVG graphic, which then can be used to create a seat selection Webform element. That’s an amazing feat and I’m confident we can find even more ways to make the best use out of this feature.

This sponsored feature demonstrates the flexibility, openness, and collaboration that makes any idea or business requirement a possibility using Drupal.

If you want to sponsor a feature, please read my blog post and create a ticket in the Webform module's issue queue.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective. More support means more input with regard to enhancing accessibility and that is always a good thing.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Oct 23 2019
Oct 23

About submission limits

Submission limits allow site builders to define how many submissions are allowed per webform, source entity, or user. Once a submission limit is met, a custom message is displayed. Submission limits per user and source entity can be used to create a dedicated user/information profiles, and are also trackable via tokens and by placing the 'Submission limits' block.

Submission limits can be used to restrict the number of event registrants or job applicants and are defined as webform settings that can be entered via a webform's submission settings page.

Webform Submission Limits

Webform Submission Limits

About option limits

Options limits allow site builders to specify how many submissions are allowed per an element's options. Elements that support options include a select menu, checkboxes, radios, and buttons. Option limits can be defined per option with a custom message append each option. The custom message can display the limit, remaining, and total submission. Once an options limit is met, the option can be disabled or removed. Once all option limits are another custom message is displayed. Finally, an element's option limit progress is tracked via a dedicated report.

Option limits can be used to limit the number of event registrants per room or used to track a product inventory. Option limits are defined as configuration settings using the 'Options limits' handler.

Webform Options Limits

Webform Options Limits


Sponsoring a feature

This new options limits feature was sponsored by Steve Babbitt from Mile3 (https://www.mile3.com/). Mile3 had a client who needed this feature. Steve read this blog post and decided to reach out to me via the Webform module's issue queue.

If you want to sponsor a feature, please read my blog post and create a ticket in the Webform module's issue queue.

Backing the Webform module

Open Collective is providing us, Drupal, and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Oct 17 2019
Oct 17

When it comes to slow and broken digital user experiences, none of us has any patience. When someone can't access a website to get the information they need, they click the browser's back button and move on to the next link in their search results. Drupal has continually improved performance by adding a powerful cache management layer to Drupal 8. Meanwhile, any time database changes are deployed to a Drupal website, the recommended and default behavior is to display the below maintenance page across the entire website including the homepage.

Site under maintenance

Site under maintenance

For better or worse, displaying Drupal's maintenance page is a broken user experience.

There are technical reasons why Drupal's maintenance page exists - end-users don't care about the technical reasons behind a maintenance page. End-users come to a website to get information. To their minds, if they can't get this information immediately (from their perspective) the website is broken. Sure, the maintenance page can provide some more information and reasons why the website is unavailable. Still, a website's digital door is temporarily shut. The expectation is that the internet superhighway is available 24/7, yet in the Drupal community we are okay with a little downtime every week or so.

We need to examine this problem and come up with some better solutions.

Why does maintenance mode exist?

The best metaphor as to why Drupal needs to display a maintenance page when deploying code and database changes is…

You can't work on a car's engine while it is driving down the highway.

Putting a Drupal site in maintenance mode is part of the steps to updating core, modules, and themes. Drush, Drupal's command-line interface, automatically switches a site into maintenance mode when deploying database changes.

Drupal's maintenance mode has been around since Drupal 4.7. Khalid Baheyeldin (kbahey) contributed the first patch in Issue #32622: Site Offline Under Maintenance feature. The Drupal community came to an immediate consensus that stands today - being able to take a site offline was and still is a useful feature.

Drupal's maintenance page provides a way to stop visitors from accessing an undesirable user experience while allowing administrators and developers to access a site.

The existence of Drupal’s maintenance mode makes sense. Even preventing a user from accessing a broken website, while a website is being updated, makes sense. The problem is displaying a maintenance page across an entire website feels like a broken user experience to end-users. The possible solutions to this problem lay in not having or displaying a broken website.

Is maintenance mode always needed?

Drupal is complex architecture with a lot of moving parts therefore, certain parts of Drupal are going to need to be updated in isolation. We can't assume that a deployment, which is working in staging/testing environment, is going to work the same in a production/live environment. Production environments are under considerable more load than any staging/testing environment. Production servers will have concurrent page requests and form submissions, which may fail as code and database records are updated and even when Drupal's cache is cleared.

I explorated with the maintainers of Drush, the possibility of allowing a developer to decide when a site should not be put into maintenance mode during database updates, and the answer is deploying code and database changes without maintenance mode can result in data loss.

The risk of data loss means we must still use maintenance mode when deploying code and database changes.

Not having a broken website during code and database updates can be mitigated by reducing the downtime. Code changes generally only takes a minute or two, meanwhile database changes can require long batch processes to be executed, and can take several minutes.

I can speak from my experience building and maintaining the Webform module Drupal 8. I have written over 150 incremental updates to Webform related configuration and data schemes. There might be an opportunity to review and rethink how certain aspects of Drupal's Update API works. Maybe a module maintainer can explicitly state that a specific update hook requires a website to be in maintenance mode.

Stepping back from the technical challenges and issues around deploying code, what is needed when deploying changes to a production environment is...

A safe environment that won't have any data loss and provide the optimal user experience.

How to provide a safe environment for deploying updates?

When I initially stated that a site's homepage is replaced with Drupal's maintenance page when changes are deployed, I ignored the current poormans workaround, which is most enterprise sites are heavily cached by a reverse proxy. When changes are deployed, the reverse proxy can continue to serve cache pages. In many cases, a site appears to be up and running for most anonymous users as long as they are requesting cached pages, as soon as they click a form's submit button or login they will see a maintenance page. The approach of relying on cached pages during deployments is the recommended solution for most Drupal hosting providers.

Serving a cached site is essentially providing users with a "read-only" user experience, except certain actions will unexpectedly result in a maintenance page. This solution still provides a somewhat broken and unpredictable user experience. The notion that a read-only version of website can be served to end-users when deploying changes made me wonder…

Instead of displaying a maintenance page site-wide, could a site be switched to read-only mode during deployments?

What is a read-only mode?

In the Drupal community, "there is always a module for that" and Sharique Farooqui (Sharique) has created a Read only mode module which…

"Provides an alternate to the built in Maintenance Mode in Drupal. Instead of displaying a static text file to users while the site is in maintenance mode, Read Only Mode will allow access (reading) of new content while preventing the addition of new content (posting / submitting forms / etc)."

In read-only mode forms are replaced with the below message.

Site is currently in maintenance. During this maintenance it is not possible to change site content (like comments, pages and users).

A read-only Drupal instance should...

  • Allow users to access content. 
  • Disable content editing, comments, and webform submission.
  • Display custom messages when a user can't create or update content.

An interesting nuance to read-only forms and comments is that if the application data is being stored remotely, a site may not have to disable forms and comments. For example, if a website uses Disqus for comments, then it would not need to disable comments. If a webform does not save results to the database and the webform either sends email notification or remote posts submission data to third party server; a site's webforms might also not need to be disabled.

How can a site safely be switched to read-only mode?

The read-only mode must prevent the creating, updating, and deleting any records stored in the database. Ideally, the entire database should set to read-only access. If you know how complicated a Drupal site can be, this is not realistic. The critical thing is for the read-only mode to prevent users from writing data that might be lost.

Another challenge is this: if a site is set to read-only while code and database updates are being executed, it is still possible to run into cache clear, locking, and performance issues. The best solution is to create an isolated read-only instance that is independent of the production instance while code is being deployed.

Enterprise Drupal websites use load-balanced servers to increase reliability and availability through redundancy. Most Drupal hosting providers have some form of redundancy where if a server stops responding the website will failover to another server. Load balancers support calling a health-check script, which monitor's the server's database and filesystem. The health check script is called every few seconds. If a server's database or filesystem becomes unavailable, the load balancer will direct user traffic to a stable server.

We can apply a similar approach to create load-balanced environment in which a site is switched to maintenance mode and user traffic is directed to an isolated, read-only instance of a website.

Here is a step-by-step look at leveraging a read-only server during a Drupal code and database deployment.

  1. A dedicated read-only copy of a production Drupal site is set up. The "read-only" site needs to be configured to always enable the Read only mode module. 
  2. The read-only Drupal site is synced with production nightly or manually. The read-only site must never be synced during a deployment.
  3. A health check script is set up on the production site which returns FALSE when a site is switched to maintenance mode.
  4. When the production site is switched to maintenance mode, the load balancer, using the healthcheck, should direct all traffic to the read-only site.
  5. Once the production site switches off maintenance mode, the load balancer should now direct all traffic back to the production site.

What are some of the downsides to a read-only server?

A load-balanced read-only server is not a perfect solution. End-users will still not be able to submit certain forms and comments. Adding another server to a load balanced hosting environment increases infrastructure costs. Fortunately, the read-only server is not used frequently and by being read-only, requires less computational resources.

What is missing and what is next for deploying an enterprise Drupal website with minimal downtime?

This blog post is just walking through a proof-of-concept of leveraging a read-only server during code and database deployments. Everything discussed needs more thought, work, and community contribution. I suspect some enterprise Drupal sites have come up with other and possibly better solutions to reducing downtime during deployments.

In a previous blog post, I talked about how companies within open source should work together to solve shared and challenging problems to benefit the broader community. Improving deployments is a challenging problem that is impacting everyone in the Drupal community. Reducing downtime during deployments helps everyone, especially the customers of Drupal hosting providers. I am sure this question is asked to every hosting provider, and I am optimistic that hosting providers can contribute their ideas, solutions, and resources to solving this problem.

The next step is for an organization or hosting provider to implement a full proof-of-concept and document what it takes to minimize downtime during deployments using a read-only server.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Oct 07 2019
Oct 07

Recently, I nudged governments to get more involved in fixing accessibility issues in Open Source projects. Getting governments to do anything can feel like a monumental challenge. Maybe we need to build better alliances and then collectively lobby the governments to change how they approach Open Source.

Dries Buytaert, the founder of Drupal, recently published a blog post titled, "Balancing Makers and Takers to sustain and scale Open Source," and while reading it I wondered, “Are we approaching the problem of sustainability too much as developers? Should we step back and look at the challenge of sustainability from a business and political perspective?”

Is changing an Open Source project's license going to change how other organizations contribute to Open Source? Changing the licensing is a different approach. The recent "Open-source licensing war" felt like a few individual companies are trying to make a significant shift in Open Source, however lacking a unified front. If Open Source companies are going to take on Amazon, they are going to have to do it together by building alliances.

The definition of alliance sounds very much like what happens in Open Source communities.

An alliance is a relationship among people, groups, or states that have joined together for mutual benefit or to achieve some common purpose, whether or not explicit agreement has been worked out among them.

-- https://en.wikipedia.org/wiki/Alliance

Political alliances (a.k.a. parties) are what powers most governments. The scale of some open source projects has required better governance. In Dries' blog post, he spends time exploring how organizations use Open Source (a.k.a. Takers) without helping to build the software or community (a.k.a. Makers). His post ends with three valuable suggestions that are focused on appealing to organizations and rethinking how the Open Source software is shared. Maybe we need to rethink how Open Source communities and organizations work together.

"Working better together" is a mantra in Open Source. In the Drupal community, we work together to build the 'software' and the Drupal Association is supporting the infrastructure.

Are there other opportunities to work together?

Deciding and maintaining a local development environment is a challenge for every developer. In the Drupal community, each hosting company is developing its own Docker-based local develop environment. Wouldn't everyone benefit from one collaborative Drupal-specific local develop environment? Competitors can work together for the common good, primarily when everyone benefits from the collaboration.

The Drupal community does work well together - we know this. A few years ago, Drupal got off its island and started leveraging other Open Source projects including Symfony. There is even an implementation for WordPress' Gutenberg page builder available for Drupal.

Besides sharing code across Open Source communities, we need to start collaborating to improve sustainability.


Open Source is about collaboration. The problem of Open Source sustainability is going to be best solved by improving and rethinking how we collaborate.

We need to collaborate to get the organizations that rely on Open Source to contribute more.

Onboarding new contributors to Open Source is a critical process of building sustainable Open Source communities. Aside from emphasizing the importance of onboarding individual contributors, we need to also look at how we onboard new organizations and encourage their collective effort to help sustain the software they need.

Drupal's Getting Involved Guide targets individual contributors. For example, nowhere on the Events page does it say, "Organizations can get involved by sponsoring an event." If the Drupal community wants bigger contributions and a more sustainable ecosystem, we need to target organizations. If one fortune 500 company decides that content moderation and workflows are essential for the future of their organization's business and contributes this code back to the Drupal community; this makes a huge difference.

For the past twenty years, Open Source advocates had to be evangelists preaching the value of Open Source. Open Source is here to stay, and most evangelists are now preaching to the choir. Even this type of blog post is preaching to the choir of people who care about Open Source and sustainability. I am not ready to state that Open Source needs to go on a crusade to solve the challenge of sustainability. Dries' blog post explores how Open Source has become a public and common good with different types of governance for Open Source. Maybe we need to embrace the inevitability that governments gradually have to get involved in some aspects of Open Source.

The scale at which Open Source software is impacting our society leads to governments needing to get more involved in coordinating and supporting. As I stated in my blog post governments should take responsibility for the accessibility for the Open Source projects that their constituents rely on. Similarly, the usage and success of self-driving automobiles is not going to take-off until a centralized shared open network of information and software is created to coordinate millions of self-driving cars, trucks, boats, and planes. The misconception in my blog post's statement that "governments should do this or that" misses the reality that governments need to be pushed and lobbied to take action and make changes.

Lobbying is not a word commonly found in Open Source. 

Lobbying, persuasion, or interest representation is the act of attempting to influence the actions, policies, or decisions of officials, most often legislators or members of regulatory agencies

-- https://en.wikipedia.org/wiki/Lobbying

Lobbying is not an entirely new concept for Open Source. Julia Reda and the Free and Open Source Software Audit (FOSSA) project successfully persuaded the EU to offer bug bounties. These bug bounties helped address security issues in many Open Source projects, including Drupal.

Security and accessibility in Open Source are two big digital concerns for governments that they should help support and address. Governments want to build secure and accessible digital experiences; they need guidance on how to properly do it. For example, the U.S. government's Healthcare.gov website faced numerous issues during its launch and it needed a lot of help getting it right. The same administration also passed a policy demanding 20 percent of federal code be open source. Maybe the next administration should pass a policy or create a department to address accessibility and security in Open Source software. Most governments understand the value of Open Source, and they need help becoming better members of the Open Communities.

Who should persuade and help the government to contribute more to Open Source?


I chose not to title this post, "Drupal, WordPress, and GitHub should lobby the government" because it’s not realistic to expect an Open Source community to lobby governments. Open Source communities are still working through the challenges of self-governess. I chose to call-out three companies, Acquia, Automattic, and Microsoft, because they are all major contributors and drivers to Open Source projects in different ways. Acquia supports Drupal, a Content Management System (CMS) used to build enterprise digital experiences. Automattic supports Wordpress; the most popular CMS and blogging platform used by 33.5% of all the websites. Finally, Microsoft is the largest contributor to GitHub and now they own GitHub. It is also important to note that Microsoft knows how to lobby the government. Microsoft could pave the way in convincing the government of the importance of contribution.

All three companies are paying teams of developers to help contribute, build, and maintain Open Source projects. I see in the Drupal community an assumption that Acquia is or should be doing most of the heavy work within the Drupal community. An Open Source project is not going to be sustainable, assuming one company can keep hiring full-time developers. At the same time, of course, these companies need to continue to invest in their respective Open Source software and community.

As I have written about Open Source sustainability, I keep returning to the proverb.

"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."

Companies like Acquia, Automattic, and Microsoft, which are valuing and contributing to Open Source should step-back and teach (or nudge) other organizations to start contributing to or to contribute more back to Open Source. Secondarily, businesses and Open Source leaders need to collaborate to make all off Open Source more sustainable.

Open Source began with evangelists converting developers building proprietary software to share and collaborate their ideas and passion.

Open Source evangelists may need to become lobbyist who persuades the 'Takers' of Open Source to contribute something back help sustainable Open source software.


Generally, I don't directly want to ask someone to take action in the Open Source community. However, I am invested in its continued growth and I know from experience we have amazing resources within our existing (and growing) community. Frankly, everyone in Open Source, including the leadership, has contributed more than their fair share. I am nudging the leaders of Open Source projects to look at the challenges they are facing in their community, to approach the problem differently, and take a different action. Maybe working together to lobby governments to fix accessibility issues in Open Source would be an excellent place to start to improve Open Source sustainability.

When I watch the below video, it is clear that the project leads for Drupal and WordPress are passionate and committed to Open Source. They share a common ground and would be able to work together - I am confident of this.

Microsoft may seem like the odd-man out. Years ago, Microsoft even lobbied against Open Source. Microsoft decided to change their approach and invest in Open Source. Now, Open Source communities and their leaders need to change their approach and collaborate to make Open Source sustainable.

Everyone understands why organizations should contribute to Open Source. The question is how can we persuade (a.k.a. lobby) organizations to contribute. Together, I know we’ll find the answers.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Sep 16 2019
Sep 16

The things that make me most excited about the pending release of Drupal 9 in June 2020 is that as a community we have the opportunity to look back at what we have accomplished, let go of some old deprecated code, and can now start thinking about what is next for Drupal 10.


To my mind, the biggest accomplishments with Drupal 8’s release was shifting it’s entire code base and community to be more object-oriented. The adoption of Symfony into Drupal core allowed us to build a more robust and flexible Content Management Framework. The Webform module for Drupal 8 is a testament to how healthy Drupal has become as a framework. Its robustness is a combination of Drupal's Plugin API and Form API with object-oriented concepts, including dependency injection. A straightforward and personal statement is.

Drupal 8 made me a better programmer and software architect.

Looking at the code and concepts behind core and contributed modules, it is immediately apparent that everyone stepped back and reapproached a lot of technical challenges - our collective hard work and contributions resulted in great solutions and better code. Core improvements are documented as initiatives on Drupal.org. Contributed projects generally don't have initiatives. When you look at the flexibility behind a "simple" module like Metatag, maintained by Damien McKenna (DamienMcKenna) or something potentially as "complex" as Domain Access, maintained by Ken Rickard (agentrickard), it’s impressive to witness what is being built and maintained by the Drupal community.

I think it’s safe to say that everyone is ready to keep improving our software and let go of some of the technical baggage, aka deprecated code.


While Drupal 8 has evolved, some code has become deprecated and replaced by better code and design patterns, allowing us to improve the software. In Dries Buytaert's post, Plan for Drupal 9, he states…

"Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backward-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality."

Regarding deprecation, what isn’t said but is worth mentioning is that some code is deprecated to improve the underlying software architecture and fix mistakes like bad naming conventions or unneeded complexity. When the Drupal community adopted Symfony, we entered uncharted waters and mistakes are going to be made.

Recently, I started sketching with my ten-year-old daughter. An important lesson I’m trying to teach her is that it is okay to make mistakes, especially because you can always fix them later. Making mistakes is part of the process in wanting to improve something. Within art, the term 'mistake' is open to interpretation. In software development however, we know when code smells bad and have a process in place to refactor bad code.


"Bad smelling code" is an extreme statement which frankly I would only use to describe my code.

Fixing bad smelling code is going to cause a bump in the Webform module's road to Drupal 9.

Before I explain the specific issue in the Webform module for Drupal 8, I want to emphasize that the Drupal community is in good shape with a plan to move on to Drupal 9.

Since Dries' published the plan for Drupal 9, people have been busy coordinating the Drupal 9 initiative. Matt Glaman (mglaman) created Drupal Check, a tool which helps everyone find and remove deprecated code. Now, everyone needs to start removing deprecated code from their module.

Several contributors have been helping me remove deprecated code from the Webform module. Removing a deprecated service from a class constructor that which relies on dependency injection seemed impossible, but then Shawn Duncan (FatherShawn) demonstrated to the NYC Drupal Meetup an implementation pattern, which properly extends a class and safely injects dependencies.

The simplest explanation I can give for non-technical users is the Webform module failed to make it easy to extend the Webform module without having hardcoded tightly coupled dependencies. In other words, some things are going to break when the Webform is installed via Drupal 9. On top of making it easier to extend, applying this new implementation pattern reduced code complexity. This change record on Drupal.org provides a more technical explanation with a code example of the improvements.

It’s also important to acknowledge that Shawn learned this pattern while attending Alex Pott's presentation, Drupal 9 is coming: Getting your code ready. Alex credits Lee Rowlands (larowlan) and Thomas Seidl (drunken monkey) for documenting how to safely extending Drupal 8 plugin classes without fear of constructor changes.

In Alex's presentation, he recommends.

"Be very very careful with sub-classes and overriding constructors"

Sadly, I wasn't aware of how to properly sub-classes and override constructors while building the Webform module, and now we have some technical debt that needs fixing.

We must fix the sub-classing and overridden constructor problem because it paves the Webform module's road to Drupal 9. Fixing this issue is a massive patch that is going to break any Webform add-on or custom code that implements a Webform element or handler and overrides the constructor. Breaking backward compatibility in Drupal core or contributed module requires tagging a new version. Therefore, we are going to have bump the Webform module's version from 5.x to 6.x to get ready for Drupal 9.

I think everyone is starting to understand the bad news, which is that Webform 6.x is going to break some code. This change will result in fatal show-stopping errors, which are easy to fix. Developers need to apply the implementation pattern documented in the change record. Because most patches and changes to the Webform module do not alter a class' constructor, there is some good news: We should be able to maintain a Webform 8.x-5.x and Webform 8/9.x-6.x branch at the same time.

Following the tradition established over the last three years, any significant bump to the Webform module's release status has been tied to the New Year.

Along with preparing for Drupal 9, the 8/9.x-6.x branch of the Webform module will include any significant API changes or improvements. For example, I would like to fix how conditional logic handles a disabled element's value.

Another significant and thankless task that needs to be accomplished is migrating all the Webform module's SimpleTests to PHPUnit. Fortunately, many people have thanked me by backing the Webform module's Open Collective. Now there are funds available to pay for the monotonous task of migrating dozens of tests.


Last year's stable release of Webform 8.x-5.x was a Christmas present, and I hope everyone understands that this year's upcoming tagging of Webform 9.x-6.x is not a lump of coal but a big step in the Webform module's road to Drupal 9 and beyond.

I rarely get to commit a patch that makes my code easier to maintain. I am thankful for Shawn Duncan (FatherShawn), recognizing how cool and important this implementation pattern was during Alex's presentation and then sharing it with the NYC Drupal community. This is how the hive mind that is Open Source works to build Drupal. The Drupal community should thank everyone involved who helped transitioned our code and community to Drupal 8. In a few months, we can thank them once again for continuously improving and refactoring Drupal core and contributed projects and paving our road to Drupal 9 - collectively and collaboratively, we’ll get there...it’s what we do.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Sep 03 2019
Sep 03

I have spent my two previous blog posts exploring how requesting an appointment online begins a patient's digital journey and how top US hospitals approach online appointment request forms. Now, I would like to make some recommendations and strategies for building an exemplary appointment request form and follow it with an explanation on to how these recommendations are being applied to the Webform module's "Request a Medical Appointment" form template.


Creating an exemplary appointment request form is an iterative process that requires experimentation and testing with analytics to determine which solutions work and which ones don't.

There are many different levels of statistics that can be captured from a form.

The most immediately available statistic is the form's completion rate, which indicates how many people successfully filled out and submitted the form. Subtracting the completing rate from how many users visit the form provides a general sense of the form drop-off rate. What is missing from these statistics is more nuanced information about the form's drop-off rate that can give a better understanding of the form's user experience.


Tracking a form's events shows which inputs were filled in and in what sequence they were entered. This detailed information helps to determine how a user is interacting with a form. Furthermore, knowing where users drop off from completing a form can help indicate which questions may need to be removed or reworked.

Analytics provides the digital team with insights that lead to experimentation and testing.

A good iterative process should always including testing, which makes sure that changes and improvements are successful.


Forms built using an iterative process typically have some current version of the form where inputs or labeling could be improved. The best way to confirm that an improvement or experiment is successful is to perform an A/B test where the original and improved variant is randomly presented to end-users, and each variant's success rate is tracked and then compared.


At some point, the best way to get direct and helpful feedback about an appointment request form is to ask users their opinion. User testing an appointment request form is tricky because you risk inconveniencing potential patients. Large healthcare institutions should consider doing professional usability testing with real patients who volunteer and are compensated for their participation. Seeing and hearing a user's frustrations with an appointment request results in inspiring a digital team to care more about the patient's experience.

Personally, my experience watching user testing made me realize that the most important thing that needs to happen on an appointment request form is that a patient is able to book an appointment, even if it requires them to make a phone call. Always include a phone number on an appointment request form.

On a related note, witnessing and understanding how users with disabilities navigate a website, inspires everyone to care about accessibility.


There are a lot of resources about form design and usability that provide general form recommendations. The goal here is to highlight common suggestions and recommendations explicitly applicable to appointment request forms.



Make it easy for users to find the appointment request form. Appointment request forms should be accessible within three clicks from a hospital's homepage.


Create landing pages that route users to the correct appointment request form. Landing pages can route domestic and international patients to the proper form and direct referring physicians to doctor portals.



Set expectations by indicating how long and what type of response is expected. For example, will patients receive a confirmation email with a callback within 24 hours?


Group related inputs by type of information. Common groupings for appointment request forms include contact, patient, diagnosis, and insurance information.


Explain why specific healthcare information is needed. Tell users why providing insurance, referring physicians, and diagnoses will help when booking an appointment.


Only collect the relevant information required to complete the immediate task of booking an appointment. Scrutinize each input and question and ask is this information needed.


Make sure the layout inputs are easy to understand and complete. Top aligned labels are the recommended approach for mobile and desktop forms.


Use conditional logic to ask simple yes/no questions which then ask for more specific answers. For example, asking who is filling out the form should be one of the first questions on all appointment request forms.


Clearly indicate what inputs are required or optional. If most of a form's inputs are needed, it may be more appropriate to note which inputs are optional.

Required elements should come before optional elements. Placing the required inputs first makes it easier for patients to skip optional inputs.

Make sure users with disabilities can complete the form. Forms should fully accessible to screen readers and keyboard navigation.

The Webform module's templates are intended to provide a starting point. Site builders and architects can customize the suggested elements and information for their specific business requirements.

Request a Medical Appointment Template

Request a Medical Appointment Template

Please note: The new 'Request a Medical Appointment' template is only available to new installations of the Webform module using the latest release of Webform 8.x-5.4+. Otherwise, you can manually install the webform.webform.template_medical_appointment.yml via Drupal's Configuration Management UI (/admin/config/development/configuration/single/import) or API.


Accessibility should not be an after-thought. Appointment requests need to be easy to understand and complete for all users.


For mission-critical forms, it is best to avoid any unnecessary JavaScript enhancements or behaviors that can cause accessibility issues. This is why the appointment request template avoids using Select2 to enhance select menus. There is a fascinating related discussion happening on Drupal.org about improving the usability and accessibility of long select lists. Ben Mullins (bnjmnm) is doing a fantastic accessibility audit of several of the available select menu enhancement libraries.


Forms should show an explanation of required (*) fields, so I decided to display the 'Indicates required field" message at the top of the form.


The appointment request form is configured to display a native browser warning message when a user navigates away from a form with unsaved changes. Because the warning is generated from the web browser and not custom JavaScript, screen readers and other devices for people with disabilities should adequately handle this behavior. For example, Gmail also uses this functionality when a user is about to lose unsaved changes.


The goal of the appointment request is to collect patient and caregiver information. Therefore, it is key to ask for this information directly and make it clear what information is required to complete the form.

For example, the caregiver and patient contact information inputs ask for the same type of information. This makes it easy for an end-user reviewing the form to know that they need the caregiver's or patient's first name, last name, phone, and email.


This appointment request form tries to keep the labeling as simple as possible. Because the form targets patients and caregivers, it is challenging to create generic labeling that addresses both audiences. In the past, I have written custom JavaScript, which conditionally changes form element labels and descriptions based on the audience. For example, a caregiver would see 'Patient First Name' and a patient would see 'Your First Name.' This approach becomes unmanageable. There are no form builders on the market that support conditional form element labels and description. Conditional form element labels and descriptions would be a tremendous and challenging feature for the Webform module to explore.


Required elements always come first. Besides indicating which elements are required, all the medical information is denoted as (optional) because a care specialist can also collect this information during the appointment scheduling phone calls.


For phone numbers, I nudge the user to enter the phone number using the standard US format (XXX) XXX-XXXX. Still, we don't need to require users to enter this format. Once again, I avoid using a JavaScript enhancement, like a phone number input mask. Input masks create an accessibility issue for screen readers because the (__)-___-____ is read aloud as "opening parenthesis, underscore, underscore, underscore, closing parenthesis, dash, etc."


The appointment request template displays a straightforward confirmation page and deliberately does not send a confirmation email to the end-user. Sending insecure emails to a patient can be considered a Health Insurance Portability and Accountability Act (HIPAA) violation. Generally, it is recommended to use secure messaging communicate with the patient or caregiver.


Drupal and the Webform modules provide a responsive user experience out-of-box. Radios can be challenging to use on a small screen, so I decided to enhance the radios so that they would visual appear and behave like buttons.

In the Webform module, there is a dedicated buttons element that uses jQuery UI Buttons. I opted to use a recent enhancement to radios which makes it possible to style radios as buttons without using jQuery UI.


Even though single-column forms are more comfortable to complete, allowing some elements to be laid out in two columns makes it possible for someone to see the entire form and, in turn, realize that is is very easy to fill out.


Drupal's Bartik theme provides a good starting point for a form's visual design. I do find the default table element, used for the phone preferences, to be a little bit visually heavy. Phone preferences are optional and therefore should not be the most visually appealing element on the page. BTW, another reason I chose buttons for the first question, 'Who are you?", was to further draw a user's eye to this question, which is inside a container with a light gray background.


The saving of results is disabled to prevent protected healthcare information (PHI) from being stored in Drupal. The appointment request template sends a confirmation and notification email. In a production environment submissions should be remotely posted to CRM or database.


The simpler a form is to fill out, the more likely end-users will complete it. At the same time, it is important to capture the most accurate information. Since an appointment request form results in a phone call back, it is beneficial to know the best time to call a prospective patient or caregiver. I decided to experiment with adding a custom composite element allowing users to enter the best days and times to receive a callback. This widget adds complexity to the form, which is why it is optional. To further reduce this widget's complexity, I removed the adding, removing, and sorting of the days and times.

Honestly, we don't know if the enhancement is useful. If we track all the requests, we can look at how many people provide this information and how many days/times they are providing. A more direct approach is to perform usability testing that would allow us to watch end-users fill-out and submit the form.

There is always room for improvement. I hope my suggestions and tips inspired you to take a second look at your existing webforms and think differently when building new webforms. Building webforms is an iterative process and we should always welcome feedback.

I welcome any feedback to help me improve the webform's 'Request a Medical Appointment' template. Thanks for taking the time with me to research, review, and explore building an exemplary appointment request form.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Aug 26 2019
Aug 26

My previous post explores how requesting a medical appointment online begins a patient's digital journey. A hospital's appointment request form might be a new patient's first interaction with a healthcare institution. As such, it is one of the most public-facing forms for a healthcare institution, establishing the baseline for the quality of other external and even internal facing forms. The user experience of the appointment request form sets the tone for the entire patient experience.


A patient's successful user experience when finding, filling out, and submitting an appointment request form is determined by the visual, information, and interactive design of the website and form itself.

Visual design matters

Visual design identifies a healthcare institution’s brand and aesthetic. The quality of care at a healthcare institution is reflected on their website. The website's visual design should be clean, efficient, and caring. Since an appointment request form results in a call back from a live person, including a photograph of a nurse or clinician on the form or landing page can visually reinforce this expectation and experience.

Information design matters

Information design ensures that the patient understands how to navigate the form and makes it clear what information is required and what information is optional. Appointment request forms act as an ambassador of sorts, beginning an interaction between a patient and healthcare clinicians. The form's information design and corresponding editorial sets the tone of a patient's interaction with a healthcare institution.

Interactive design matters

Interactive design improves the flow and process for filling out a form. As someone fills out an appointment request form, conditional logic may hide or show different individual or groups of inputs. When a user clicks submit, how a form validates submitted data can increase or decrease a user's frustration.

Keeping the visual, information, and interactive design in mind, let's look at how the top US hospitals approach their request an appointment.

 U.S. News' Best Hospitals rankings

 U.S. News' Best Hospitals rankings


The U.S. News' Best Hospitals rankings is primarily based on the overall quality of a hospital's care, treatments, and outcomes. The U.S. News' patient experience ratings never directly ask questions about a patient's digital experience. However, the fact that the number 1 ranked hospital, the Mayo Clinical, has a 'Request Appointment' link on the U.S. News' Best Hospitals landing page reinforces the importance of this form.

Mayo Clinical's 'Request Appointment' link

Mayo Clinical's 'Request Appointment' link

We are going to look at how the top four hospitals allow patients to request an appointment on their individual websites. We will examine the positives and negatives to each hospital's appointment request form. The goal is to extrapolate some recommendations and best practices which can be used to build an appointment request form template for the Webform module for Drupal 8.

It’s essential for us to see how users navigate to the appointment form from a hospital's homepage. We will examine how many inputs, questions, steps, and conditions are included on a form, and then determining the level of effort needed to complete a form. Finally, we want to assess the overall user experience, which encompasses the visual, information, and interactive design of the form.

Mayo Clinic

Mayo Clinic's Request an Appointment

Mayo Clinic's Request an Appointment

On the Mayo Clinic's home page, the appointments link is the first and largest element on the page. It takes three clicks from the home page to navigate to their appointment request form. The appointment request form contains 20-30 inputs depending on who is completing the form. Inputs are grouped by contact, insurance, and medical information. Most inputs are required.

Information matters

On top of the U.S. News' direct link to the Mayo Clinic's appointment form as well as the prominent appointment link on the Mayo Clinic's homepage, Mayo Clinic's appointment landing page does a great job of providing all the relevant contact information needed to make an appointment by phone. This ensures even if a patient can't complete the form, they can call the hospital. This contact information, with links to dedicated international and referring physician form, are then included as a sidebar on Mayo's appointment request form.

Experimentation matters

The goal of this blog post's exploration is to identify best practices and recommendations, which helps to establish a baseline for a good appointment request form. Once there is a baseline, it also helps to experiment to improve a form's user experience

Typically, required inputs are marked with red asterisks. Since most inputs are required and there are only a very few optional inputs on the form, Mayo's team inverts the normal, more common, approach of noting required inputs. Instead, they include the message, "All fields are required unless marked optional" with a right aligned "(optional)" label next to optional inputs. This approach appears to be successful. The more important lesson is to be cognizant of a form's required and optional inputs.

Layout matters

The form groups related inputs into visually defined and well-labeled sections. The form also uses a vertical layout with left-aligned labels. Left-aligned labels are more difficult for users to comprehend the relationship between inputs and labels. Alternatively, the form's mobile layout uses the recommend top-aligned labels approach, and it is easier to fill-out. Mayo Clinic should experiment with using top-aligned labels for the desktop form and see if it increases the forms completion rates.

Improvement matters

Mayo Clinic values and promotes their appointment request form. The Mayo's Clinic digital team has put a considerable amount of thought, care, and consideration into their appointment request form's user experience. They should continue to experiment, test, and improve this form.

Cleveland Clinic

Cleveland Clinic's Online Appointment Request Form

Cleveland Clinic's Online Appointment Request Form

The Cleveland Clinic's homepage also includes a prominent link to appointments. It takes three clicks from the home page to navigate to the appointment request form. Their appointment request form is a multistep form with five pages and contains between 50-90 inputs. Most inputs are required. The form collects information about patients, caregivers, referring physicians, and comprehensive medical history. Entering this much information takes a considerable amount of time to complete.

Design matters

Cleveland Clinic's forms is a beautifully designed and logically arranged multi-step form. Multi-step forms makes it easier to collect a lot of information. It is important to ask, "Does an appointment request form need to collect a lot of information?"

Time matters​

When it comes to digital experiences, people have less patience. How long it takes to complete a task matters. Does a new patient need to supply their marital status or subscribe to a mailing list to book their first appointment? Wouldn’t it be more appropriate to collect a patient's medical history after the appointment is booked?

Information matters

Relating to how long it takes to fill out an appointment request form, it is important to ask the value and purpose of each question. Cleveland Clinic's form asks, "Has the patient been seen at Cleveland Clinical in the past?" if answered "Yes", the form then proceeds to ask for a Medical Record Number (MRN). It makes complete sense to collect an existing patient's MRN, which can be used to look up a patient's medical history. However, once the patient provides an MRN, does the form still need to obtain a comprehensive medical history?

Failure matters​

Asking for too much information increases the likelihood that a patient or caregiver might not be able to complete a form or result in them being frustrated with the process of completing the form. Let’s not forget the appointment request form facilitates a phone call that ultimately results in an appointment. Cleveland Clinic's form should also include the phone number on every page to ensure if someone is frustrated they can pick up the phone and still book an appointment.

Goals matters

Cleveland Clinic's form is an overwhelming user experience. At the very least, users should be given the option to complete a more straightforward appointment request form, but also provided a secondary option to provide a full medical history

Before even building any form, it helps to summarize the goal of the form with the scope of the information being collected. This summary can also become the form's introduction text. For public-facing forms, each input should be scrutinized to determine if the information is required to complete the immediate task at hand.

Johns Hopkins Hospital

Johns Hopkins Hospital's Request an Appointment

Johns Hopkins Hospital's Request an Appointment

The Johns Hopkins Hospital homepage includes a small icon with a label linking to their appointments landing page. It takes four clicks from the home page to navigate to the appointment request form. Their form contains 20-25 inputs with five optional inputs. The form has one conditional question asking, "Who are you seeking care for?"

Simplicity matters

By and large, the Johns Hopkins Hospital's appointment request form is the simplest form that we are going to review. There is no input grouping and it has a straightforward two column layout. This, despite the fact that grouping related inputs using top-alignment and a one column layout, is generally recommended. The simplicity of this form makes it easy for users to understand how much information is required to fill out the form. Having all the required inputs displayed before any optional inputs also makes it easier for a user to fill in the form quickly. The two column layout does make the form more difficult to fill out. When the browser is resized to a mobile layout, the form is easier and faster to fill out. Making a form easy for everyone to fill out, including users with disabilities, is essential.

Accessibility matters

The Johns Hopkins Hospital's appointment request form is not accessible to users who depend on screen readers. The form's inputs are missing the necessary code, which allows screen readers to accurately describe to an end-user the labels for each input. Instead of a screen reader saying something like, "Input first name required" the screen reader just states, "Input required" for all the form's inputs.

The inaccessibility of the Johns Hopkins Hospital's appointment request form is a significant problem. An inaccessible appointment request form is the equivalent to not having a wheelchair ramp to enter a building. Fortunately, this issue is not hard to fix. The John Hopkins Hospital digital team needs to become more aware of and monitor the accessibility of their forms.

Expectations matters

Nowhere on the Johns Hopkins Hospital's appointment request form does it indicate the patient or caregiver will receive a callback within a defined period of time. The Johns Hopkins Hospital's appointments landing does include this information. This information should be repeated at the top of the form just in case the user has not been to the appointments landing page. Users need to know what to expect when the click submit on a form. In the specific case of an appointment request form, users need to know when (i.e. how many days) and how they will be contacted (i.e., phone or email).

Massachusetts General

Massachusetts General's Request an Appointment

Massachusetts General's Request an Appointment

The Massachusetts General's homepage also includes two links to appointments. It takes three clicks from the home page to navigate to the appointment request form. The appointment request form contains 20-25 inputs in three groupings with only two optional inputs. Yes/no conditional logic is used to ask for more information about the patient and referring physician

Tone matters

Massachusetts General's appointment request form asks questions using a tone that guides the user through the process of completing the form. For example, every hospital wants to know if a patient has insurance. Instead of displaying a large dropdown menu labeled "Insurance", Massachusetts General's form states, "To facilitate processing, please provide insurance plan name if known." Using this type of phrasing explains to a user why this information is needed, while also stating it is optional. This is an excellent example of the relationship of asking the right question with collecting the best answer.

Questions matters

Many patients decide which hospital to be treated based on physician referrals. When intaking new patients, hospitals may need to contact a referring physician to get a patient's medical history. Most appointment request forms ask for the referring physician's contact information as individual inputs. Massachusetts General's appointment request form just asks for the "Name of referring provider, facility name, address and phone if known." This approach is a brilliant and deliberate decision. First off, it makes it very easy for a patient to enter what information they have about their physician ensuring that at least some information is collected. Appointment requests are always reviewed by an actual person who can take the plain text physician information, fix a misspelling, look up the referring physician's NPI (National Provider Identifier), and get all the needed information into a new patient's medical record.

Massachusetts General appointment request form is asking some very well thought out questions, which are being supported by the right process.

Consistency matter

Massachusetts General has an exemplary appointment request form. There are no immediate issues that need to be addressed by their form. Ironically, Massachusetts General's international appointment request form does have some design and user experience issues. Without getting into specifics, most of the problems on international appointment request form would be resolved if this form followed the best practices and care established by the domestic appointment request form. Providing a consistent user experience across an institution's webforms can ensure a better patient experience.

An appointment request form is a small but key piece to the complex puzzle of a patient’s experience and journey. Soon, someone is going to disrupt, change, and simplify this puzzle. For example, people will be able to schedule an appointment using voice-controlled systems. When we look at the user experience of these relatively simple appointment request forms, there is still some work to be done now and moving forward.

We have extensively explored four hospitals appointment request forms. In my next blog post, I am going to make some concrete recommendations and strategies for building an exemplary appointment request form.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Aug 19 2019
Aug 19


My experience with healthcare, Drupal, and webforms

For the past 20 years, I have worked in healthcare helping Memorial Sloan Kettering Cancer Center (MSKCC) evolve their digital platform and patient experience. About ten years ago, I persuaded MSKCC to switch to Drupal 6, which was followed by a migration to Drupal 8. More recently, I have become the maintainer of the Webform module for Drupal 8. Now, I want to leverage my experience and expertise in healthcare, webforms, and Drupal, to start exploring how we can improve patient and caregiver’s digital experience related to online appointment requests.

It’s important that we understand the problem/challenge of requesting an appointment online, examine how hospitals are currently solving this problem, and then offer some recommendations and ways to improve existing approaches. Instead of writing one very long blog post, I’m going to break up this discussion into a series of three blog posts. This initial post is going to address the patient journey and experience around an appointment request form.

These blog posts are not Drupal-specific, but my goal is to create and share an exemplary "Request an appointment" form template for the Webform module for Drupal 8.

Improving patient and caregiver’s digital experience

Improving the patient and caregiver digital experience is a very broad, massive, and challenging topic. Personally, my goal when working with doctors, researcher, and caregivers is…

Make it easier for patients to find the care they need as well as make it easier for caregivers to give the care that patients need.

Making things "easy" for patients and caregivers in healthcare is easier said than done. Healthcare systems are complex machines with multiple players dealing with different siloed technologies. Complexity in healthcare leads to a lot of frustration, which has become expected and accepted when entering into a doctor's office or hospital, or going online to file an insurance claim. The best way to make something easier is to simplify it.

Patients and caregivers want a simpler digital experience

In technology, the biggest disruptors of different industries share a commonality of making things simpler. Ride-sharing services, like Uber and Lyft, have disrupted the taxi and limousine industry by making it simple and easy to book-a-ride using a phone. In healthcare, services like ZocDoc, empower patients to book doctor appointments on a computer or phone. Healthcare systems and hospitals need to recognize that a simpler digital and in-person experience is what consumers want. Simpler digital experiences need to be thought about and provided by all aspects of a healthcare organization. Stepping back, we need to remember that digital is one part of a patient’s journey through a healthcare system.

Waiting room

Waiting room

Where does a patient’s journey begin?

There are dozens of doors that a patient may enter to get care; it could be a referral from a friend, an ambulance pulling into an ER, a banner advertisement, or a comprehensive search on the internet. Online searches inevitably lead to a hospital's website. A hospital's website is where many patients digital journeys begin.

A hospital's website is its digital entrance to the hospital

The notion that a hospital should envision their website as another entrance to the building gives people a tangible comparison for a patient's digital experience. The hospital should view the digital and the physical experiences as equally important. A hospital's lobby and website both need to be clean, organized, and easy to navigate. When a patient walks into a hospital or clicks on a link, we want them to know where they need to go as well as how to get the care they need. Both the website and the lobby need to have clear, straightforward instructions lest they find they have a frustrated and annoyed patient in their midst.

To get care, patients need to provide information about themselves; Who are they? What is wrong? Do they have insurance? The questions are answered using paper or digital form, which begins a patient's journey.

Forms are important to healthcare

Healthcare is driven by information. This information needs to be collected and stored. The more information that can be collected about a patient, the easier it is to provide them with the care they need. At the same time, it is also important to add that it is equally important to collect the "right" information about a patient at the "appropriate time." Obtaining the "right" information requires asking the "right" questions and collecting the most complete and accurate answers. Knowing when is the "appropriate time" to ask a question is even more challenging. For example, collecting a patient's entire medical history is not required to book a patient's first appointment. Many patient's digital experiences begin with an appointment form.

Knowing when is the "appropriate time" to ask a question is more challenging. For example, collecting a patient's entire medical history is not required to book a patient's first appointment. Many patient's digital experiences begin with an appointment form.

An appointment form begins or ends a patient's journey

Many years ago, while discussing the usability of some minor aspect of a request an appointment, I noted that:

If someone wants to request an appointment, they are going to fill out this form no matter what.

There is some truth to this statement because patients have lots of patience (pun intended) when dealing with healthcare. Would an unusable request an appointment form ultimately end a patient's journey? Probably not.

The hospital that provides the cleanest, simplest, and most accessible digital experience will distinguish themselves.

Appointment forms set the tone for a patient's experience with a hospital.

Types of appointment form

Booking an appointment online is not an easy task. Most hospital websites offer a "request an appointment'" form that collects a potential patient's contact information, which leads to someone calling the patient back to "schedule an appointment." Services like ZocDoc, allow patients to "schedule an appointment" without having to interact with a physical person. Even though we are primarily talking about a patient digital journey, we can't forget that people still pick up the phone and call to schedule an appointment. We should never underestimate the power of a phone call. For example, parents of pediatric patients need the caring voice of a live person telling them everything is going to be okay.

We are going to focus on a hospital's request for an appointment, which is used to collect the information needed to for a patient to schedule an appointment.


Recommendations for all forms

Before diving into healthcare specific forms, it helps to step back and understand what makes a form easy to understand and use. Drupal and the Webform module follows industry standard best practices around ensuring that forms are accessible to people with disabilities, available to mobile and desktop users, and provide a clean and predictable layout with standard error validation. For example, in the Webform module for Drupal, forms are laid out vertically with top-aligned labels, which have been shown make it easier for users to complete forms.

My top three general recommendations for building webform are

Keep it simple. This will reduce frustration and ensure that users will complete the webform.

Group and organize labels and inputs. The visual and information layout of a form matters. Grouping related inputs with proper labeling help users to understand what information is needed to complete a form.

Communicate what information is expected, required, and optional. Users need visual indicators that show how to complete a form and with clear error messages when data is missing.

Using the Webform module, or any other enterprise form builder, can significantly help when building accessible and usable forms. The challenge for a building a request an appointment form is asking the right questions using the best approach.

The best approach for a request an appointment form

Figuring out who is filling out the form should be the first question on any request appointment form. Knowing this single piece of information makes it possible to present the user with a form that asks the right questions. Once we know who someone is, a form can be customized, or we can direct the user to the appropriate form. For example, international appointment requests tend to require additional contact information, including callback times, which can be better addressed in a dedicated form.

Request appointment forms ask questions that lead to conversations.

Request an appointment forms are conversations

Appointment request forms result in a call back from a person, which results in conversation. Forms are essentially a digital conversation with an end user. Appointment request forms should start with general questions and lead to more specific information. The three questions that need to be answered are…

Not surprising these questions are identical to what a nurse or doctor asks when in-taking a new patient. These questions lead to the collection of different types of information which can be organized into groupings. For example, the answer to "Who are you?" is mainly contact information and the answer to "What brought you here today?" is healthcare information. Appointment requests form should guide patients through the discussion about their specific health-related issue.

In-person, when a nurse or doctor asks a question, based on the patient's answer, they will choose which question should or should not be asked next. Online forms can provide a similar user experience by using conditional logic to hide and show questions based on previous answers. Conditional logic can also be used to determine which questions should be required vs optional.

If a request an appointment form is a digital conversation, nothing about this experience should be frustrating. We want to ensure that a patient can book an appointment. With this goal in mind, every appointment form should include a phone number that a patient or caregiver can call to schedule an appointment.

Once the conversation has ended via the patient submitting the form, make sure to confirm their appointment request. Then, tell the patient what to expect next.

How top US hospitals approach their online appointment request form?

My next blog post is going to examine how top US hospitals (ranked by US News) are handling online appointment requests. Before reading my evaluations and opinions, you might want to visit the Mayo Clinic, Cleveland Clinic, Johns Hopkins Hospital, and Massachusetts General's appointment request form and ask yourselves if I was a new patient…

  • How would I feel when filling out these request an appointment form?

  • Are these appointment request forms providing a good digital experience?

  • What type of patient journey would one expect at this institution?

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Aug 13 2019
Aug 13

We need to nudge governments to start funding and fixing accessibility issues in the Open Source projects that are being used to build digital experiences. Most governments are required by law to build accessible websites and applications. Drupal’s commitment to accessibility is why Drupal is used by a lot of governments to create ambitious digital experiences.

Governments have complex budgeting systems and policies, which can make it difficult for them to contribute to Open Source. At the same time, there are many consulting agencies specializing in Drupal for government, and maybe these organizations need to consider fixing accessibility issues on behalf of their clients.

Accessibility is one of the key selling points of Drupal to governments.

If an agency started contributing, funding, and fixing accessibility issues in Drupal core and Open Source, they’d be showing their government clients that they are indeed experts who understand the importance of getting involved in the Open Source community.

So I have started this blog post with a direct ask for governments to pay to fix accessibility issues without a full explanation as to why. It helps to step back and look at the bigger context: “Why should governments fix accessibility issues in Drupal Core?”

Governments are using Drupal

This summer’s DrupalGovCon in Washington, DC was the largest Drupal event on the East Coast of the United States. The conference was completely free to attend with 1500 registrants. There were dozens of sponsors promoting their Drupal expertise and services. My presentation, Webform for Government, included a section about accessibility. There were also four sessions dedicated to accessibility.

Besides presenting at DrupalGovCon, I also volunteered a few hours to help with Webform-related contribution sprints focusing on improving Drupal’s Form API’s accessibility. I felt that having new contributors help fix accessibility issues would be a rewarding first experience into the world of contributing to Drupal core.

Fixing accessibility issues in Drupal

At the Webform contribution sprint, Lera Atwater (leraa), a first-time contributor, started reviewing Issue #2951317: FAPI #radios form elements do not have an accessible required attribute. She reviewed the most recent patch and provided some feedback. I was able to re-roll the patch a few times to address some new remaining issues and add some basic test coverage. The fact that Lera and I focused on one issue helped move it forward. Still, our solution needs to be reviewed by Andrew Macpherson (andrewmacpherson) or Mike Gifford (mgifford), Drupal’s accessibility maintainers and then Alex Bronstein (effulgentsia) or Tim Plunkett (tim.plunkett), Drupal’s Form API maintainers. Getting an accessibility-related patch committed is a lot of communication and work.

This experience made me ask…

How can we streamline the process for getting accessibility patches committed to Drupal core?

Streamlining the process of fixing accessibility issues

The short answer is we can’t streamline the process of documenting, fixing, and reviewing accessibility issues. These steps are required and needed to ensure the quality of code being committed to Drupal core. What we might be able to do is strive for more efficiency in how we manage accessibility-related issues and the steps required to fix them.

While working on this one accessibility for free in my spare time, it made me wonder...

What would happen if a paid developer collected and worked on multiple accessibility issues for a few weeks and managed to move these issues forward towards a resolution collectively?

First off, I can tell from experience that most Form API and accessibility-related issues in Drupal Core as well as other Open Source projects are very similar. Most accessibility issues have something to do with fixing or adding Aria (Accessible Rich Internet Applications) attributes or keyboard access. A developer should be able to familiarize themselves with the overarching accessibility requirements and fixes needed to address the multiple accessibility issues in Drupal core.

Second, developers tend to work better on focused tasks. Most developers contribute to Open Source in their spare time completing small tasks. Paying a developer to commit and focus on fixing accessibility issues as part of their job is going to yield better results.

Finally, having multiple tickets queued for core maintainers is a more efficient use of Andrew, Mike, Alex, and Tim’s time. Blocks of similar tickets can pass through the core review process more quickly. Also, everyone shares the reward of saying we fixed these accessibility issues.

Governments should pay to fix accessibility issues

I’d like to nudge people or organizations to get involved. In the last month’s Webform 8.x-5.3 release, I settled on the below direct message within the Webform module’s UI.

My conclusion is that we need to directly ask people to get involved, and directly ask organizations to contribute financially (a.k.a. give money). I am admittedly uncomfortable asking people for money because I think to myself, “What if they say no?”

No one should say no to fixing accessibility issues.

The Drupal community cares about accessibility, governments have to care about accessibility, and governments rely on Drupal. Governments should pay to fix accessibility issues.

Talking Drupal and the U.S. Government

Before DrupalGovCon, the Talking Drupal podcast spoke with Abby Bowman about Drupal for Gov. They discussed the U.S. government’s usage and contribution to Drupal and Open Source. From Abby, I learned two interesting things about the U.S. government’s commitment to Open Source.

First, the U.S. government contributes code to Open Source via Code.gov. Second, the U.S. government requires all websites to be accessible, but there is no central department or team, ensuring that all government websites are accessible. All the U.S. government’s websites would immediately benefit from having a team dedicated to finding and fixing accessibility issues.

If you want to hear about my experience at DrupalConGov check out Talking Drupal #221 - Live from GovCon.

How can government and organizations start paying to fix accessibility issues?

The word “pay” is liberally used throughout this post to emphasize the need for governments and organizations to budget for and commit to spending resources for fixing accessibility issues. Either a government related-project needs to get someone on their team to fix accessibility issues or nudge (a.k.a. pay) a vendor or outside developer to fix accessibility issues.

We have to keep asking and experimenting with how we ask organizations to contribute.

Companies that work for governments should pay to fix accessibility issues

In an ideal world, governments should pay to fix accessibility issues. Realistically, some agencies in government can’t directly contribute to Open Source. As stated earlier, any outside vendor who works for the government can contribute to Open Source. Saying that “We care about accessibility and fix accessibility issues within Drupal” is a great slide to include in a pitch deck for a government project.

Maybe governments can mandate that vendors are contributors to the Open Source projects that are being used by a government project.

What is realistically possible?

Realistically, we need to need to fix the accessibility issues in Drupal and Open Source projects. Everyone in the world should have equal access to digital information and services. Every government needs to ensure that the software they are relying on is accessible.

In Drupal and Open Source, we ask individuals, organizations, and governments to get involved. Nudging governments to fix accessibility issues in Drupal and Open Source is just a very direct ask to fix a very specific problem that affects everyone.

There are two immediate ways for governments to get involved in fixing accessibility issues. Either governments dedicate resources to address the problem or they push their vendors to start addressing accessibility issues. In the Open Source community, we need to further embrace and encourage this type of contribution.

Embracing and encouraging governments and organizations contributing to Open Source

In the Drupal Community, we always acknowledge the individuals contributing to Open Source by listing maintainers and contributors on the project pages and even in the software’s MAINTAINERS.txt. We do recognize organizations supporting a Drupal project, but maybe we need to do more. In this day and age, we put corporation names on stadiums. Open Source has reached that scale that the organizations and government that contribute to Open Source are equally important as the individuals. Notably, in the case of enterprise-focused software like Drupal, where organizations are the target consumer, we need to figure out how to get these organizations involved and adequately acknowledged.

Acknowledging that we are already doing a lot

The Drupal community has accomplished something pretty amazing. We have one of the most accessible and secure Open Source Content Manager Systems on the market. We care about accessibility and security and work hard to fix and improve them. As a community, we need to always strive to grow and evolve. Nudging governments to get more involved in fixing accessibility issues will help make our software more accessible to everyone.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Jun 12 2019
Jun 12

In my post, Drupal is frustrating, I stated that enterprise websites need, want, and are willing to pay for better support options when using Open Source software. Organizations have reached out to me as a Webform module subject matter expert (SME) seeking to start a 1-to-1 support relationship. Occasionally, these relationships result in a sponsored feature request. Sometimes organizations want to ask me a simple question or at least know that I am available to answer questions. In the past, I shied away from the idea of setting up regular office hours because it would be an unpaid commitment of my time during business hours. Fortunately, with the existing funds collected by the Webform module's Open Collective, I feel that now is a good time to experiment and set up some initial office hours for the Webform module.

About office hours

The goal of office hours is to make it easier for me to help people and organizations with questions and issues related to the Webform module for Drupal 8 as well as to assist current and future Webform module contributors.

Sponsor office hours

Sponsor office hours are intended to help backers of the Webform module's Open Collective with any Webform related questions or challenges. These office hours will be strictly for monthly sponsors and backers of the Webform module's Open Collective.

Add-ons office hours

Add-ons office hours are for anyone in the Drupal community building Webform add-ons and extensions that are being contributed back to the open source community. The goal of these hours is to help support and improve the quality of the projects and community around the Webform module.

Office hour guidelines

I've been thinking about how to efficiently structure office hours for maximum efficiency, therefore I've decided to publish some guidelines. Consider these a starting point, they will likely evolve over time.


  • Office hours will be once a month for 1 hour on Fridays at 11 AM EST.

  • Maximum of 4 topics per hour.

  • Discussions per topic will be limited to 15 minutes.

  • Topics must be limited to only the Webform module for Drupal 8.

  • Office hours will be posted as an event to the Webform module's Open Collective.

  • Discussion requests need to be posted as a comment to the "[Office Hours]" ticket in the Webform Issue Queue.

  • All participants agree to follow Drupal's code of conduct.

  • Discussions may be recorded and posted to YouTube.

Sponsor office hours


  • Answer questions

  • Provide guidance

  • Reduce frustration

  • Ensure success

Open to

  • Sponsors who contribute more than $50 USD per month

  • Individuals or organizations who contribute under $50 USD per month may join two office hours per year.

  • Individuals or organizations who make a one-time $50 USD contribution can join one upcoming office hour.


Possible topics

  • Webform add-on review and recommendations

  • Creating custom handlers, elements, and exporters

  • Theming and styling questions

  • Project plan review

  • Reviewing project requirements

Add-ons office hours


Open to


Possible topics

  • Creating integrations with third-party services

  • Implementing webform elements

  • Adding webform support to contributed modules

  • Code review and recommendations

Office hours payment

Maintainer/contributors are going to be compensated $125 USD for each online office hour with an additional 30-60 minute preparation time. Office hours can be extended for an additional hour as needed.

About the $125 USD hourly rate

The hourly rate of $125 USD is meant to be starting place between what a U.S. based agency charges and a freelance consultant. This rate is based on the $100 USD per hour rate established in 2014 via the Drupal 8 accelerate program. The additional $25 USD is to account for a 5-year cost of living increase.

Final thoughts about office hours

Support is a significant issue within Open Source and Drupal. Developers generally enjoy the experience of sharing code and ideas but supporting the code is not as rewarding. No one wants to provide free support, yet everyone wants to know an open source project is supported. The more maintainers can make themselves available to individuals and organizations, the stronger the community and code is around a project. Sponsor office hours provide tangible and more reliable support for the Webform module. If you need more support around the Webform module, consider backing the Webform module's Open Collective and sign-up for the next sponsor office hours.

Open source works best when the community around a project grows and more people get involved in contributing code and ideas. The main purpose around the Webform module's Open Collective is to strengthen and support the community around the Webform module and Drupal. Add-on office hours are intended to encourage mentorship and code contribution to the Webform module and Drupal community. If you have an idea that you want to contribute back to Drupal or need help getting involved in the Drupal community, sign-up for the next add-ons office hours.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


May 21 2019
May 21

Three years ago, I started to talk about "coming to an agreement within the Drupal community and sponsoring a Webform feature." In that blog post, I discussed creating a reusable and free-to-use agreement template with a defined process which could make it easier for organizations to sponsor feature requests. Now I want to share my current process for handling sponsored feature requests to the Webform module for Drupal 8.

For the past three years, organizations have reached out to me for paid support and feature requests. Adding the ability to import submissions was a feature request paid for by Kennesaw State University. Only two parts of my transaction with Kennesaw State University were publicly visible, the issue on Drupal.org (#2902977) and a blog post.

Sharing my process for handling paid feature requests will hopefully clarify how organizations can sponsor a feature for the Webform module and other Drupal and Open Source projects.

Steps for sponsoring a feature

Sponsoring a feature can be broken down into four key steps:

  • Communication

  • Documentation

  • Agreement

  • Payment


Good communication is one of the keys to the success of any Open Source project. Currently, there are several approaches to initiating the communication process for a sponsored feature.

The easiest and most immediate way to start a sponsored feature request is to create a user account on Drupal.org and then create a feature request in the Webform's issue queue. This feature request becomes that starting point for documentation. The act of creating this ticket begins a discussion, via comments, involving those interested in sponsoring the work and the initial requirements.

Sometimes, organizations are not exactly sure what the scope of work needs to be and may want to reach out to one of the project's maintainers or contributors via Drupal Slack or email using the maintainer or contributor's Drupal.org contact form. When reaching out to a maintainer/contributor, it helps to have written requirements in advance, even if it is a single paragraph or a one-page summary of the problem/challenge.

BTW, I am referring to the person doing the work as a maintainer/contributor because sponsored features don't have to be limited to only a project's maintainer. Open source software development relies on the maintainer-to-contributor relationship. Maintainers and contributors are entitled to be compensated for their contributions.

Once a method of communication is established, a sponsor and maintainer/contributor can begin to document the problem(s) that the feature request is intended to solve, the proposed solution, and the scope of work, all using an issue on Drupal.org.


Using Drupal.org's issue queue to document a sponsored feature request allows us to leverage the community's standards and best practices for managing issues. The Drupal community has worked together to define and continually improve how we communicate within our issue queues. Creating a good issue is essential for paid and unpaid contributions. The issue summary template provides us with a starting point for documenting a feature request.

Aside from leveraging the Drupal's community's existing issue queue to collaboratively define the scope of work, there is another bonus to this public process: Transparency. Transparency makes it easier for everyone to collaborate - it provides the opportunity for various interested parties to weigh-in on a feature request's problem and solution.

Realistically, potential sponsors might decide not to pay for a feature. This frequently happens in private responses to proposals. When a publically-defined feature request is rejected, we do not have to throw it away into a digital trash bin. The hard work and collaboration between a sponsor, maintainers, and contributors can sit in the issue queue and be marked as postponed or even closed. In the future, it is not uncommon that another interested party or organization will have the same or a similar feature request. An individual or organization could review the postponed or closed feature request and decide to sponsor it or do the work themselves; ultimately sponsoring the feature.

Optimistically, a sponsor will agree to the scope of work and request a cost estimate with a timeline and agreement.

With Open Source and Drupal, community collaboration is built on mutual trust and goodwill. This is reinforced by the GPL license. Further, once the stakeholders have communicated and documented the nature of the paid feature, once it is built there is an explicit understanding that it must be contributed directly back to its Open Source project. Therefore, the general protections from GPL remain inherently applicable. The GPL, along with transparency, helps us to overcome some of the challenges for coming to an agreement. Since the work is publically available, and ownership, intellectual property, and even confidentiality clauses are not needed for the signed agreement, this streamlines the legal process. All that is required for a signed agreement is the scope of work, timeline, and payment.

The simpler the terms are for an agreement, the more likely people are to sign it. I found the most straightforward approach is to paste the entire issue from Drupal.org into a Google Document, add a summary, estimated cost, notes, timeline, payment, and very basic sign-off. Here is an example of a basic template with an example issue.

This basic template makes some assumptions with limited legal protections for both parties, with a fair assumption that both the sponsor and maintainer/contributors are good citizens with good intent.

Good intent has made it easy for me to build a few sponsored features because frankly, I have limited the scope and cost of paid features to reduce risks. No one has not paid me for a sponsored feature, and so far the worst case possible scenario is that I don't get paid for a day or two of work. That all said, the work is at least contributed back to Open Source.

Nonetheless, we want to ensure that we are paid for the work. Any standardized agreement template needs to continually be reviewed and improved. Finding and paying for a professional review and recommendations for a reusable creative commons scope of work and agreement template could be a good use of the Webform module's Open Collective funds, which are intended to help sustain, support, and improve the code and community around the Webform module and Drupal.

I have found the most significant challenge and hurdle to getting paid by a client is going through their payment processing. Everyone has different workflows for processing and paying invoices. A common and recommended approach is to get 50% at the start of a project and 50% at the completion. This is the best way to build trust and reduce risk.

At sign-off to an agreement, a simple 50% invoice can be emailed and processed. Here is the invoice template that I am currently using for sponsored features.

How payment should be handled depends on the client and maintainer/contributor. There are two possible approaches for processing payments. The more traditional method is a direct payment from the sponsor to the maintainer/contribute. A more transparent approach would be to use the Webform module's Open Collective as an intermediary.

Using the Webform module's Open Collective as intermediary might make organizations feel more comfortable sponsoring a feature because the funds are being transparently exchanged. There is the inherent benefit to a public transaction, which is that it reinforces the need for trust and good faith between the sponsor and maintainer/contributor. Some of us, including myself, also cringe at the potential conflicts that can happen during a paid project, which could then be compounded by a public dispute.

The notion that "funds are being transparently exchanged" can feel awkward and also uncomfortable. We also should not dismiss the fact that Open Collective retains 14% of every transaction as overhead. Personally, I prefer private transactions via my personal S-corp in order to retain as much of the revenue from my work as possible. I have built a fair amount of trust in the Drupal community and organizations currently seem more comfortable paying an individual company vs. transferring funds to an Open Collective, which is a new and unknown entity. However, there are conditions where participants in a feature request may not know each other and the Open Collective method will be preferred by both parties.

Giving back to the community​

The fact that the process and result of a sponsored feature are immediately contributed back to the project benefits all parties involved, including the community. Making it possible for an Open Source developer to be paid for their time makes their contribution more sustainable. Still, Open Source projects require infrastructure and money to succeed.

The process for sponsored features via a project's issue queue does rely on Drupal.org's infrastructure. Shouldn't the Drupal Association, which is responsible for Drupal.org's infrastructure, benefit from this transaction? Should both participants in this transaction be members of the Drupal Association? Should a small percentage of this transaction be contributed back to the Drupal Association? How we take paid transactions and properly give a share back to the community is not so simple.

Ideally, we should insist that anyone sponsoring a feature join the Drupal Association and back the Webform module's Open Collective. One concern with this approach is that requiring people and organizations - especially those new to the Drupal community - to do something like register for and pay for organizational memberships can discourage them from getting involved. For now, we should nudge them to be good citizens and establish trust within their Open Source community by supporting the software and community that they rely on.

Addressing some hesitations and concerns​

Sponsoring a feature is a paradigm shift; feedback is always welcomed. As I have talked about sponsored features and Open Collective with people, they have expressed a reasonable concern that Open Source is meant to be "free". The word "Free" in Open Source is open to many interpretations and I want to share my interpretations and thoughts.

Open Source software was never meant to be free software that’s built by developers working for free. Many people and organizations are paid to contribute to Open Source. Most of these transactions are happening behind closed doors with varying approaches. Many open source projects need to be supported and funded to succeed. Open Source started out, and still, is an evolving experiment and collaboration continuing to change the world. There is nothing wrong with paying people to do good work, especially if companies are benefiting from the use of that open source software.

Making it possible for anyone to be paid to contribute to an open source project will remove barriers and diversify our community. My goal is to strengthen our community and to make our collaboration more sustainable.

How do we get started?

The first step is figuring what you might need and then creating an issue on Drupal.org. From there we can start working through the process of documenting your requirements, coming to an agreement, and processing a payment using and improving these templates.

If you want to take a much larger, bolder, and significant first step that earns trust and shows good will, please join the Drupal Association and back the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


May 07 2019
May 07

To be competitive with enterprise form builders, the Webform module for Drupal 8 needs to support the downloading and exporting of submissions as PDF documents, as well as sending PDF documents as email attachments.

The Entity Print module does a great job of generating PDF documents from entities and fields, but webform submissions don't use Field API. This limitation has required site builders and developers to create custom Entity Print integrations for the Webform module.

The Webform module now includes a Webform Entity Print integration module, which handles downloading, exporting, and attaching generated PDF documents. Additionally, the Webform module allows the generated PDF document's header, footer, and CSS to be customized.

When enabled, Webform Entity Print module automatically displays a "Download PDF" link below all submissions and adds a download "PDF documents" option to the available export formats. Attaching PDF documents to emails requires that you add an "Attachment PDF" element to a webform and then configure email handlers to "Include files as attachments."

The below screencast and presentation walks through customizing the PDF link and template, exporting PDF documents, and attaching PDFs to emails.

Scratching my own itch

Adding PDF support was not a sponsored feature. I wanted the Webform module to support this advanced feature; so I created it. I was scratching my own itch.

When contributing to Drupal, the goal is often to optimize the project for personal needs ("scratching our own itch"), but it has to be bigger than that.

-- https://www.drupal.org/about/values-and-principles

The bigger itch/the challenge that I am always scratching at is:

The Webform module should provide all the features expected from an enterprise proprietary form builder combined with the flexibility and openness of Drupal.

Competing with other form builders

Competitive enterprise, and also Open Source form builders, tend to put this PDF functionality behind a paywall. For example, WordPress's Gravity Form (https://gravitypdf.com/) and Ninja Form (https://ninjaforms.com/extensions/pdf-form-submission/) charge for this type of functionality. This defeats some of the purpose behind Open Source, which is to foster collaboration. For example, both of these form builders then had to implement PDF generation using custom APIs.

Ben shared his code

In the Drupal community, we openly share our code and APIs. Ben Dougherty (benjy), the maintainer of the Entity Print module, shared his code with the Drupal community. The Entity Print module is one the most well thought out and cleanly executed Drupal 8 modules that I have seen. Ben’s hard work made it easy (and enjoyable) for me to add PDF support to the Webform module.

Thanks, Benjy

Everyone should thank Benjy for building and maintaining the Entity Print module.

If you want to thank and encourage me to continue scratching my own itch, please also consider backing the Webform module’s Open Collective and help make the Webform module that much more awesome and more sustainable.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!


Apr 29 2019
Apr 29

Learning how to manage communication and support within the Webform issue queue is something that makes me very proud. I also want to keep improving everyone’s experience within the Webform issue queue. A while back, I started welcoming new contributors and saying thank you. Frequently, I have to direct general support questions to Drupal Answers. Occasionally, I have had to remind people to be mindful of their tone. I am continually seeking ways to improve my process and communication within the Webform module's issue queue.

At Drupalcon Seattle, I took part in a discussion about strategies for effective and inclusive group communication where I was introduced to the "nudge theory".

A nudge makes it more likely that an individual will make a particular choice, or behave in a particular way, by altering the environment so that automatic cognitive processes are triggered to favour the desired outcome.

-- https://en.wikipedia.org/wiki/Nudge_theory

Besides nudging people towards the desired outcome, which is a healthy and sustainable Open Source collaboration, clearly defining these nudges will also make it easier for everyone to improve the overall support and community within the Webform module's issue queue.

Types of nudges

There are three types of nudges within most issue queues - they can be categorized as:

  • Welcome and thank you

  • Values and principles

  • Guidance and directions

Welcome and thank you

Saying a proper welcome and thank you helps set the overall tone of our collaboration. The act of saying "welcome" to a new contributor establishes that we are an inclusive community where everyone is welcome to join. Saying 'Hi' (aka nudges) to new users also reminds other members of the community to be understanding and supportive of someone entering a new community.

Following up someone's contribution with a thank you comment or even handshake (aka nudges), acknowledges and values their hard work and encourages them to keep contributing.

Value and principles

Digital spaces provide anonymity with a lot of freedom of expression. We want everyone to feel comfortable with their own identity and respectful of their unique contribution to Open Source. Ultimately we want everyone to play nicely together, which is why online communities establish a code of conduct. The Drupal community has a code of conduct which embodies the community’s values and principles. Codes of conduct can be perceived more as rules meant to prevent conflicts, while values and principles lean more towards ideals and beliefs. Reminding someone of Drupal's values and principles can feel like a more subtle nudge versus citing misconduct. In the Drupal community, our code of conduct and values and principles are so closely intertwined there is a lot of overlap; values and principles sound less finger-pointy and disciplinary. Values and principles foster engagement and provide growth, support, and direction.

Guidance and directions

Providing guidance with good directions make everyone's experience better. Honestly, no one knows exactly what they are doing in Open Source and Drupal because we are building software through one giant collaboration with a community that is in a constant state of flux. When entering a new community, it’s nice to have some direction and guidance on how to interact and contribute to the community. Within the Drupal community, people should understand how they should interact with the code, issue queue, each other, and where they can find help.

Updating the Webform module's issue submission guidelines

Providing clear information and guidelines helps to improve our collaboration. It is important to nudge and remind ourselves that everyone has good intentions when creating a ticket in an open source project's issue queue. Below are the updated submission guidelines for the Webform module. I know these guidelines are verbose and require some scrolling. At the same time, they also provide us with little 'hello' snippets of useful nudges that can be cut-and-pasted within issue queue comments, which can help everyone get the most out of our collaboration and community

Below is the updated submission guidelines, which everyone will now see when creating a new ticket in Webform module's issue queue.

Welcome and thank you

Welcome to the Webform module's issue queue, everyone is invited to participate.

Everyone is a volunteer. Please have patience and respect - we are all here to help one another and share our ideas, code, and passion.

Thank you for helping make the Webform module and our community a little better and stronger.

Values and principles

Guidance and directions

Even though all documentation and issues are in English, not everyone in the Drupal community is a native English speaker. Please take your time writing and reading each other's issues, comments, and communications. If something is confusing, please ask or provide clarification.

Please read the issue queue handbook before posting. Follow the priority and status guidelines. Only set the priority to "critical" if you are reporting a bug that causes data loss.

To prevent duplicate tickets, please search the issue queue before creating any new issues. If you find an open related issue, feel free to join the discussion by posting a comment. Generally, old and resolved issues should remain closed and linked to from a newer related ticket.

Please use the issue template to provide a detailed and focused summary for a single issue. This will make it easier for everyone to help you solve or fix your problem or challenge.

The Webform module's issue queue is for bugs, feature requests, and planning. Please post general support questions to Drupal Answers. You can also ask questions or help answer questions on the #webform channel on Drupal Slack.

Check out the Webform module's articles, video tutorials, and cookbook to find additional help and documentation.

Please review attached patches by applying them to your local development or by using Simplytest.me.

Patches and ideas are always welcome. Please provide automated test coverage for bug fixes and improvements, which can cause regressions or unexpected issues.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Apr 08 2019
Apr 08

Response to request

After posting my request for a Webform logo, Jeff Masigan (jeffmasigan) the owner of Pixel Architect Web Design Inc. reached out via Drupal Slack, offering to design the Webform module's logo and even have it printed on tee-shirts for DrupalCon Seattle. It is hard to turn down the prospect of giving out Webform tee-shirts at the Advanced Webform session. Lili, my 10-year-old daughter, is very excited to have Webform tee-shirt added to her growing Drupal tee-shirt collection.

Two other awesome members of the Drupal community, Christian Okpada (ojchris37) and Jürgen Appel, responded with proposals and ideas. While thinking about Jeff's Webform logo tee-shirt offer, I also realized that Jeff and I had met in the Webform issue queue via Issue #3032244: Webform - Route Not Found Exception. This issue was one of those frustrating 'gotcha' problems that we were able to work through and fix. Seeing that Jeff had a history in the Webform issue queue and even earned an issue commit credit, this finalized my decision to work with Jeff and Pixel Architect.

Drupal Seattle was only a few weeks away, so Jeff and I came up with a tight timeline and got to work.

First designs

Webform Logos

Webform Logos

Pixel Architect's designer came up with a bunch of icon and color variations. I initially thought the Webform logo might use a checkbox icon but when I saw the miniaturized contact form; I was sold. First off, a contact form is the only out-of-the-box form installed by the Webform module. Second, this default contact form is used in most Webform related presentations and screencasts. Finally, including a form in the logo captures the mission of the Webform, which is to build awesome forms.

So my vote is for mini contact form logo but Youri van Koppen (MegaChriz) and Christian Okpada (ojchris37) weighed in preferring the WF logo. Four people's opinions only represent a tiny sampling of the close to 500,000 installations of the Webform module, so Jeff and I decided to let people vote on the Webform module's logo at DrupalCon Seattle.

The two Webform logo finalists

The two Webform logo finalists

The two Webform logo finalists

Jeff and I are splitting the cost of hand-out cards encouraging people to vote on the Webform module's logo. Since these cards are somewhat self-promoting, the Webform module's Open Collective's fund won't be used to pay for these. I am still trying to figure out how to reasonably and adequately spend Open Collective funds.

The Webform logo and tee-shirts, which are a great use of collect funds, would not be possible without the organizations and individuals who are backing Webform module's Open Collective.


Who wants a tee-shirt?

At DrupalCon Seattle, I will have a dozen or so Webform tee-shirts to give away after my Advanced Webform session on April 11th at 9:00 AM.

Outside of my presentation, I am going to prioritize giving these tee-shirts out by:

  • Webform maintainers
  • Backers of the Webform module's Open Collective
  • Someone who will wear this tee-shirt at DrupalCon.
Attend Advanced Webforms presentation to win a Webform t-shirt

Attend Advanced Webforms presentation to win a Webform t-shirt

Vote on your favorite Webform logo

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Apr 04 2019
Apr 04

Webforms for Healthcare

I am looking forward to talking about my experiences in implementing webforms for healthcare.

This presentation will be my first time discussing the Memorial Sloan-Kettering Cancer Center's (MSKCC) implementation of the Webform module. I am even going to show the MSKCC project, which inspired me to build the Webform module for Drupal 8. This presentation will approach the topic of "Webforms for Healthcare" from two different angles.

The three big digital concerns for healthcare

First, we are going to explore Webform features and add-ons to address core digital concerns, accessibility, privacy, and security. Accessibility and privacy are important topics that are going to be discussed throughout the Healthcare summit.

The three big digital concerns for healthcare

The three big digital concerns for healthcare

The three primary audiences for healthcare

Second, we are going to explore how to leverage Webforms to address healthcare's three primary audiences for Clinical Care, Research, and Education. Each one of the audiences has a different use case and requirements. After twenty years of working in the healthcare industry, I also know that doctors need to be included in all aspects of healthcare.

The three primary audiences for healthcare

The three primary audiences for healthcare

Join us at the Drupal Healthcare Summit

Join us at the Drupal Healthcare Summit on Tuesday, April 9th. Throughout the day we are going to talk about patient experiences, education, privacy, inclusion, accessibility, and more…


If you can't join us at the Drupal Healthcare Summit, you can watch my pre-recorded practice presentation below…

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Apr 01 2019
Apr 01

Proceeding every article or blog post about the future of Drupal, there are always a few comments that express a high-level of frustration when it comes to Drupal 8. From missing modules, to completely rewritten APIs, to new design patterns, and even complaints about the restructuring of sessions and tracks at DrupalCon….People are frustrated with change. The entire Drupal community understands peoples’ frustration, which is why we are continually trying to improve the software and community. Our most significant strides happen at DrupalCons, where everyone comes to together to share codes, ideas, and passion.

Introspection before DrupalCon

Before last year’s DrupalCon I wrote a blog post titled, Drupal is the worst Content Management System except for all those other solutions in which I talked about Drupal adoption, sustainability, and mentorship. DrupalCon provides the Drupal community with an opportunity for everyone to take stock of where we are at and where we are going. Every year we have discussions with actionable items to improve our community, which is continually changing.

Each year, I get something different out of DrupalCon. Last year I became more aware of diversity and inclusion issues within the Drupal and software community. I was also inspired to address webform related accessibility issues. The overarching thing I have learned at DrupalCons is contributing to Open Source is more than writing code, it’s about collaboration and community.

Come for the code; stay for the community

What I like about this quote is it acknowledges two key aspects to Drupal - the code and community - with the code being the “what” that brings us together. The code might also be what is most frustrating to people coming and staying with Drupal. But, getting frustrated as a community, is still a connectedness - we’re all invested in the code, together.

Our Lego analogy is broken

There are many articles expounding that Drupal's modularity is like Lego building bricks.

For example, Rob McBryde's post, Drupal vs. WordPress - A Lego Analogy states…

"Drupal is like Lego Technic where you can build whatever you can imagine with little to nothing ​preformed."

We are promoting that Drupal is as flexible and as easy as Lego building bricks which can be endlessly combined to build anything. Omitted from this analogy is that some of Drupal's bricks don't fit together, sometimes they don't work as expected, they might be missing, and sometimes stop working; this is incredibly frustrating.

Imagine getting a box filled with bright colored plastic bricks with no particular directions, and occasionally there are some broken or missing blocks. Once you determine something is missing, you’re supposed to go out and find that missing piece or build it yourself.

Drupal is no longer as simple as a pile of Lego bricks; meanwhile, our projects do require master builders.

Ambitious digital experience with enterprise support

It took me a few years to fully respect that Drupal is for "Ambitious digital experience" when we are competing directly with enterprise content management solutions. Shouldn't we be honest and include the word "enterprise" in our software description? Enterprise companies are relying on Drupal as a key part of their digital strategy and infrastructure. When we look at the gestalt of everything that organizations are doing with Drupal and as a community what were are trying to build - it can’t be denied: it is ambitious.

We need to recognize that for organizations to build their ambition digital experience they need enterprise-level support.

Drupal has succeeded in inspiring Fortune 500 companies to embrace Open Source without a clear roadmap on how to do it properly. These are huge companies with clear missions, and Drupal is a flexible and powerful tool used to help these companies succeed. Companies have no issue paying for support, yet it is unclear in the Drupal community how to get support.

Do you contract an agency? Hire your own team? Contribute code directly back to Drupal? Sponsor a camp? Join the Drupal Association? Help fund the Drupal project?

The answer is all of the above. Providing and receiving enterprise support for Drupal is a multifaceted approach, which is not universally and clearly communicated to organizations. The most immediate example of this problem is Drupal.org's support page is developer centric. We need to promote better support within the Drupal community. It needs to be perceived as a priority by those using it - this perception, will in turn, quite naturally create a greater sense of responsibility and investment to those of us writing code, fixing bugs, and sharing ideas. Our drive to collaborate and make something great, even better is already there - consistent recognition and support will certainly motivate, encourage, and ultimately yield even better results.

Promoting and supporting Drupal

Last year, the Promote Drupal initiative was introduced at DrupalCon Nashville. At DrupalCon Seattle this initiative is going to start proposing, planning, and promoting Drupal. Having sales and marketing materials that everyone can use will help all our pitches and also establish a unified message. I am optimistic that we will be able to clearly communicate the benefits of Drupal and Open Source and persuade organizations to explore our software and community.

Our first step is convincing organizations to enter the open source Drupal waters; then we need to teach them how to swim.

On my blog, I am continually drawn back to exploring the importance of teaching and mentoring in Open Source software development.

The best teachers are not rockstars; they are mentors.

The Drupal rockstar is imaginary

I am hoping that Matthew Tift (mtift) is going to end the myth of the Drupal rockstar with his DrupalCon presentation, The Imaginary Band of Drupal Rock Stars. I was always intimidated by Certified to Rock which ranked a Drupal.org user's contribution on a scale of 1 to 10; I continually got a 3, which was frustrating and discouraging

If the notion that the Drupal rockstar is over, what should we be calling ourselves?

The term 'Drupal expert' may also be a fallacy because the most valuable people in the Drupal community are the contributors, mentors, maintainers, and leaders.

Contribution and mentoring is the key to success

There are two key steps for a person or organization to fully value and understand how to engage in Open Source. First, they need to recognize that the software is built by people freely collaborating by contributing ideas and code which helps benefit the overall project. Second, acknowledging that the open source workflow involves maintainers mentoring contributors.

Mentoring the next generation of Drupal contributors

The maintainer to contributor mentoring relationship is what builds and maintains our software. We are continually mentoring new contributors who become maintainers. Mentorship is what grows our community.

Drupal is about to hit its twenty year anniversary. Our community is getting older and older. Meanwhile, the software industry is growing with younger people filling in the ranks. Drupal is not as appealing as the new and shiny rising technologies. Still, the concept that Drupal could be the backbone content repository to an organization changing digital strategy, is a valuable and long-term vision.

Beside our software, we have a vibrant community; our product powers amazing digital experiences. The fact that our software powers large enterprise companies is a double-edge sword. It is appealing to see one's contribution is being used by and helping recognizable organizations, yet it’s also intimidating to meet the expectations of these organizations. And just as the thrill of meeting those expectations is being realized, the notion of contributing code for free - efforts benefits enterprise organizations, which have money, collides and it dawns on you: something is off here.

Open source contributions come in all shapes and sizes

Open source contributions come in all shapes and sizes, and we do a great job of documenting ways for people to get involved, but we avoid directly asking large organizations to get involved by financially contributing to Drupal. Large organizations are willing to pay for enterprise level support however, their support options are limited. Generally, enterprise-level Drupal support involves a 1-on-1 relationship with a Drupal agency (aka Drupal experts). Drupal is too big for one single agency to solve all the problems and challenges.

When we start collaborating to promote Drupal, are we also going to collaborate to improve the support for Drupal?

Every single pitch which includes Drupal as part of the solution needs to also introduce organizations to how they can get involved and support Drupal.

Compensating contributors

Recently, I worked through a few security issues related to the Webform module. I saw how valuable and important it is to have as many eyeballs as possible helping to review and secure our shared code. It is great that we are now compensating people for finding security issues.

What about paying people to fix security issues, critical bugs, or even feature requests?

Removing the frustration

Let's ask the direct question…

What is frustrating people about Drupal?

People become frustrated when something does not meet their expectations with no immediate and easy way to fix the problem and/or improve the situation.

More than a decade after Jeff Robbins' (jjeff) blog post, titled How Drupal Will Save The World documents the same frustrations and problems which we are still facing today.

"Drupal is what you want. It will solve all of the problems that you're having. But it's really hard to set up. And don't do it wrong or your site won't work at all!"

Jeff also offered some answers to…

What if we had unlimited funds to grow Drupal into its full potential as an indispensable web tool that is simple to use and lets people get control of maniacally complex data?

All of Jeff's answers boil down to collecting and distributing funds to address and solve the challenges and frustrations around Drupal and Open Source.

Funding Open Source using Open Collective

Open Collective is a service which allows Open Source projects to transparently collect and distribute funds. Organizations who back an Open Collective will get a receipt for their financial contributions and be able to see exactly how the collected money is being spent.

Having unlimited funds does not solve any problem unless the money can be properly distributed to the people who are needed to solve the problem. Since there is no such thing as unlimited funds, how funds are spent also needs to be tracked.

Open Collective has the potential of solving the funding problem hindering Drupal and Open Source, by making it possible to distribute and track funds. We need to raise awareness about what is Open Collective, individual Open Collectives, contributing funds to different Open Collectives, and finally experimenting with spending collected funds to improve our software and community.

Most of my blog posts end with a call to action to back the Webform module's and any Drupal related Open Collective. Yes, we need your funds and right now, we need your ideas. If you want to share your ideas or start your own Open Collective, please consider attending the Open Collective BOF at DrupalCon Seattle on April 10th, 2019 at 17:30.

Final thoughts

Drupal is no longer a box of colorful Lego bricks being used by rockstars to build websites.

Drupal is used to build ambitious digital experiences by a community made up of maintainers, mentors, contributors, and leaders who collaborate to build a powerful and flexible ecosystem of ideas that evolve with the continuously changing digital landscape of the world.

The challenge is supporting and sustaining our collaboration.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Mar 18 2019
Mar 18


How do you migrate webforms and submissions from previous versions of Drupal and other form builders?

The answer is Drupal's Migrate API, which is incredibly powerful but can feel overwhelming. When I migrated MSKCC.org from Drupal 6 to Drupal 8, the Migrate API was just being introduced into Drupal 8 core, and I felt more comfortable writing a custom migration script instead of using code that was still under development. Migrate API is now stable and if you are an experienced Drupal developer, you should use it.

Certain aspects of Drupal require some expertise.

The level of expertise required to build and maintain a Drupal 8 website has changed from Drupal 7, mainly because we are creating more ambitious digital experiences. The Drupal community struggles to simplify our flexible and sometimes complex product. My approach is to make the Webform module as flexible and robust as possible, while not forgetting that people need a simple way to start building a form. This is exactly why I include an introduction video on the Webform module's main page. Besides making the Webform module an awesome tool for experienced Drupal site builders, the Webform module needs to be welcoming to new users and make it easy for them to move their existing forms to Drupal.

Either an organization is starting from scratch and building a new Drupal site, or more commonly an organization has decided they need to provide a more ambitious digital experience and they have chosen to switch to Drupal. In both situations, we need to make it easy for someone to switch from other form builders to Webform.

The problem that needs to be addressed is…

How can we make it easy for an organization to migrate existing forms with submissions to the Webform module?


The simplest way to migrate to the Webform module is to rebuild an external form and then import the existing data. Building a webform is fun and easy, forms are a critical aspect to most websites; it is worth taking the time needed to rebuild an existing form, and take full advantage of all the cool elements and features available in the Webform module. The only missing feature from the Webform module is an easy and fast way to import existing submission data.

The Webform module already makes it easy to export submissions. There is a 'Download' tab under the Results section that generates a CSV (comma separated values) which can be opened in Excel or Google Sheets.

The solution is to make it extremely easy for anyone to import submissions using a CSV.

Importing a CSV containing submission data should be a simple process where a site builder uploads a CSV, which is prepared, reviewed, validated, and submitted to a webform.

Below are the steps which one might take to import CSV data:

  • Build a webform
  • Populate webform with some test submissions
  • Download the test submissions using the CSV export
  • Examine the CSV export
  • Populate the CSV export with external data
  • Upload and import the CSV export
  • Review imported data

Being able to export and import submission data as needed has the added bonus that site builders can download all the existing submissions, bulk edit them using Excel or Google Sheets, and then upload them back into the database. Submissions can now be migrated from one server to another. There is only one caveat, and it is not required, but it helps to make sure all exported and imported CSV records have a UUID (universally unique identifier).


The below notes are pulled directly for the Webform module's CSV upload form:

  • All submission properties and data is optional.
  • If UUIDs are included, existing submissions will always be updated.
  • If UUIDs are not included, already imported and unchanged records will not create duplication submissions.
  • File uploads must use publicly access URLs which begin with http:// or https://.
  • Entity references can use UUIDs or entity IDs.
  • Composite (single) values are annotated using double underscores. (e.g. ELEMENT_KEY__SUB_ELEMENT_KEY)
  • Multiple values are comma delimited with any nested commas URI escaped (%2E).
  • Multiple composite values are formatted using inline YAML.
  • Import maximum execution time limit is 6 hours.

For those hardcore developers out there, the answer is…

Yes!!! There is even a drush:webform:import command.


To make sure no one feels overwhelmed, I created the below video to help people feel more comfortable with this new functionality.

Supporting organization

This awesome new feature was sponsored by Kennesaw State University. Kaleem Clarkson (kclarkson), Operations Manager @ Center for Excellence in Teaching & Learning at Kennesaw State University, and I scoped out this ticket on Drupal.org via Issue #2902977: Provide a straight forward tool for importing submissions from a CSV document.

I previously talked about Coming to an agreement within the Drupal community and sponsoring a Webform feature, and it is challenging working out the process for a paid feature. I have discovered that scoping out all paid Webform feature requests on the Drupal.org has worked out to be the most transparent process. Even when a potentially sponsored feature agreement falls through, the scoped out work remains in the Webform issues queue. I feel better knowing the research and work I did for the feature request is not a complete loss. I have even seen a feature request sit in the queue for a few months and then someone like Michael Feranda (mferanda) appears out of nowhere and helps complete a feature like Issue #2888862: Provide a mechanism to lock a webform submission.

Getting Involved

Kaleem Clarkson (kclarkson) and Michael Feranda (mferanda) contributions show there are multiple ways to get involved in helping to support the Webform module and Drupal. Michael found a task in the Webform issue queue and started contributing code back to the Drupal community. Kaleem is not a coder, he is more of a 'master' site builder and community leader, so he found a requirement from his project, convinced Kennesaw State University about the value of contributing back to the Drupal, and they sponsored a pretty awesome improvement, which helps everyone who is adopting the Webform module and Drupal.

Sponsor a Feature

Sponsored a feature is a challenging but needed enhancement to the process of building and maintaining the Webform module. I have had some success implementing a few paid features.

Open Collective provides a transparent platform that might make 'Sponsor a feature' more natural and accessible for the Drupal community. Paying for a feature using Open Collective's payment system which provides standardized invoices could make it easier and justifiable for large organizations to financially contribute to Webform, Drupal, and Open Source.

At the same time, I still feel it is also okay to not pay Open Collective's 13-14% overhead and execute a paid feature request via a direct transaction. Either way, I am absolutely committed to scoping out all feature requests transparently on Drupal.org.

If you have a features request, please create a ticket in the Webform module's issue queue.

Backing the Webform module

Open Collective is providing us, Drupal and Open Source, with a platform to experiment and improve Open Source sustainability. If you appreciate and value what you are getting from the Webform module, please consider becoming a backer of the Webform module's Open Collective.

Become a Backer

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Mar 11 2019
Mar 11

Thank you for backing the Webform module's Open Collective

First off, I want to thank the backers of the Webform module's Open Collective. After my last blog post, Open email asking organizations to back the Webform module and Drupal-related Open Collectives, we have 14 backers and a current balance of $908.44 that needs to be spent.

I also received a comment and an email about the need for some process for paid support. It’s worth noting that the Drupal Association is exploring a paid support model for assisting with security releases. We should recognize that Drupal 8 was a major software change and it is one that is still changing the Drupal community. And while I am thinking about how the Drupal community is changing and how we can develop better support around the Webform module, one of my more immediate concerns is improving the Webform module's Open Collective, and brand is the first thing I want to address.

Improving the Webform module's Open Collective

There are some useful tips and guides for building and maintaining an Open Collective. I appreciate Pia Mancini’s statement that "A collective is not a sprint," which makes me feel comfortable taking time to build out the Webform module's Open Collective.

Defining and strengthening the Webform module's mission will help clarify to backers what they are supporting and getting from the Webform module. The product summary for the Webform module is…

The Webform module provides all the features expected from an enterprise proprietary form builder combined with the flexibility and openness of Drupal

Drupal directly completes with proprietary Content Management Systems and the Webform module is competing with 100's of proprietary form and survey builders. The Webform module is not included on any top form builder lists, even though in a feature comparison we are on par with most of these form builders, with the added benefit that Drupal and Webform is completely free for everyone to use. This is why with the launch of the Webform's Open Collective, I proposed using collected funds to improve the Webform module's marketing and brand.

Improving the Webform module's brand

The Drupal Association is actively working on promoting Drupal. At the same time, we as a community can also promote Drupal's contribute module ecosystem. There are some amazing contributed projects with equally amazing developers contributing and maintaining these projects. Besides writing quality open source software, it’s also essential to consider the big picture of an open source project. For example, the Webform module's project page's information architecture works to address every aspect of the Webform module from encouraging people to watch a video, try the Webform module, and explore documentation. The summation of a piece of software or project is visually represented by a logo.

A dedicated logo is missing from the Webform module's project and Open Collective landing pages.

I did not start this blog post with this direct ask for Webform logo because I feel there is much greater need and opportunity for the Drupal community. That said...

Better branding is missing from most Drupal contributed projects.

Improving all Drupal-related projects brand

Some Drupal projects have dedicated logos which help establish the project's brand.

  • Drupal.tv website has the word TV inside the "Drupal" drop.
  • Acquia's Lightning distribution has a lightning bolt inside the "Drupal" drop.
  • Token module has very cool looking [T].
  • Rules module has an R flow diagram.
  • Paragraphs module has a right-pointing pilcrow.

All of the above project logos demonstrate how having a visual representation helps establish a project's brand.

In the spirit of the giving back to Drupal community…

Is it possible for us to collaborate and create a logo for the Webform module that also provides a universal logo kit which makes it possible for any Drupal contributed project to have a dedicated logo?

Providing a logo kit for Drupal contribute projects

When exploring the existing project logos in the Drupal community, I feel there are two key requirements for a reusable logo kit.

First, the logo should include a visual reference to Drupal. I like the concept of using the Drupal "drop" with some icon or text placed inside the drop.

Second, the logo kit is going to need to leverage a creative common and freely available icon library, which could include something like Seven theme's Libricons or Material Design's icon.

We can use Drupal media kit's logo page as a starting point for the final deliverables.

The Webform module's logo requirements and process

Right now, the simplest icon which could be used to represent a form builder is a checkbox, but I am open to other suggestions. The logo should also optionally include the 'Webform' project name. The Webform logo may also be used with the Webform UI as a callout.

Our entire process will be transparent with all materials freely available. As this project proceeds, we will publish blog posts encouraging community feedback.

Who should respond to this request for proposal

First and foremost, you need to want to give something back to Drupal and Open Source with the understanding that your contribution will be recognized, although you will most likely not to be fully financially compensated for work.

We have only $900 USD available for this project. It is not a lot and may be too little. It might make sense for us to do a two-phase approach with the Webform logo designed in phase 1 and the Drupal contributed project logo kit part of phase 2.

I know some people or organizations might do willing to do this work for free, but it is important that you are compensated in some way because…

It is not reasonable to assume that someone is going to doing something for free because they are contributing to open source.

Proposals could be very simple with a general statement of work and timeline. Our entire process is going to be transparently done using the Drupal.org issue queue. Proposals can be posted as comments to Issue #3026111: Create a logo and header for the Webform module. Also, feel free to ping on the Drupal Slack #webform channel if you have questions.

Submit a Webform logo proposal

Thanks again

I opened this blog post thanking the existing backers of the Webform because they are making it possible for the Webform module to have a logo. Building a reusable logo kit for all contributed projects most likely requires more funds. Having a Drupal contributed project logo kit will help us strengthen our community's visual brand and presentation.

Strengthen and supporting the Drupal community is a shared goal over every Drupal related Open Collective, whether it is providing testing environments, video recordings, cloud hosting, camps, or a powerful, flexible, and open source form builder.

Please consider backing the Webform module or any Drupal related Open Collective.

Support the Webform module

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Feb 26 2019
Feb 26

Hi [person or company],


My name is Jacob Rockowitz and I am one of the proud maintainers of the Webform module. The Webform module is one of Drupal's most installed modules. It provides all the features expected from an enterprise proprietary form builder combined with the flexibility and openness of Drupal.


After three years of hard work, the Webform module for Drupal 8 now has a stable release. As with most open source projects, there is still work to be done. To help support our work, the maintainers of the Webform module have set up an Open Collective.


At [event] we spoke briefly about [company] becoming a backer of the Webform and other Drupal-related Open Collective. Open Collective provides a transparent system to collect and distribute funds to help support the Drupal community’s ongoing efforts. We are going to use Open Collective to collect funds to help build, maintain, and promote the Webform module and its add-ons and integrations. Our goal is to help everyone have a successful experience using the Webform module. For us to help you succeed, we need to know what you need.


It is reasonable that organizations may have reservations about committing resources to open source projects. For large enterprise projects, providing some financial support will ensure stability and growth. Open Collective provides an easy way for organizations to get involved. It is also possible for us to leverage Open Collective to prevent any technical hurdles from delaying your projects. For example, Open Collective can be used to push bug fixes, sponsor a feature, get support, provide training, improve documentation, and even mentorship.


Drupal, in its current form, is amazing because everyone has contributed to it in extraordinary ways. We collaborate on the code to build ambitious enterprise websites and applications. The biggest unknown when installing an open source module or theme is, "Is this software supported?" and "How can I get help?". Backing a Drupal-related Open Collective will help address both of these concerns and more.


Please consider becoming a $10 monthly backer of the Webform and other Drupal-related Open Collective including Simplytest.me and Drupal Recording Initiative.


If you have ideas on how we could use Webform's Open Collective to help you and your clients succeed, please post your comments on this blog post.


Thanks for listening,

Jake Rockowitz and fellow Webform maintainers

Feb 12 2019
Feb 12

The only way to get someone to contribute to an open source project is to ask them.

At the beginning of the New Year, I set up the Webform module's Open Collective. I knew that in order to persuade organizations to back the Webform module or any Drupal-related Open Collective would require directly asking organizations to join the Webform module's Open Collective. Additionally, I also needed to listen to what an organization might want to get out of their financial contribution to an Open Collective

It is reasonable for organizations to ask why should they back an Open Collective and what should they expect in return.

At DrupalCampNJ, I paid a visit to the event's sponsors that I was friendly with and asked them to join the Webform module's Open Collective. I also decided to broaden my pitch to include asking people to consider backing any Drupal related Open Collective. The Simplytest.me and Drupal Recording Initiative collectives provide invaluable services that our community needs and everyone should help support them.

Everyone was familiar with the Webform module, and most people knew that I was maintaining the Drupal 8 version, but no one knew what an "Open Collective" is. Gradually, as I spoke to people, I managed to put together a concise explanation for the question, "What is Open Collective?"

Open Collective is a service which allows Open Source projects to transparently collect and distribute funds. Organizations who back an Open Collective will get a receipt for their financial contributions and be able to see exactly how the collected money is being spent.

The above explanation leads to the next relevant question which is "How is this money going to be spent?" My response is this: Spending the collected funds is going to be determined by what the backers want and the Webform module needs.

As the maintainer of the Webform module, I feel we need a logo. A logo will help distinguish the Webform module from the massive sea of online form builders. For some projects, the Webform module is a significant part of a proposal and a logo would help make the software feel more professional. In the near future, I am going to post an RFP for a Webform logo. Still, what I want is not nearly as important as what organizations need.

Discussing, Explaining, Listening and Delivering

I want to hear what people want or need from the Webform module's Open Collective. Since most people did not know what is an Open Collective, it was hard to expect them to know what they need from an Open Collective. As I spoke with people at DrupalCampNJ, I came up with two anecdotes that explored some potential use cases for an Open Collective.

My first anecdote happened when I finished setting up the Webform module's Open Collective, someone emailed me asking for help with debugging a broken image file upload, and they offered to pay me for my time. These small private transactions are complicated to coordinate, so I suggested that they make a donation to the Webform module's Open Collective and then create a ticket in the Webform's issue queue. I managed to resolve their problem quickly. Everyone felt that this was a successful transaction.

Another related anecdote: While brainstorming about getting people to help pay for open source development, a fellow software developer daydreamed that his company would happily pay to see a bug fixed or merely a patch committed. One of the most common frustrations in open source issue queues is seeing a patch sit there for months and sometimes years.

The above stories highlight the fact that besides using Open Collective to back an open source project, a collective could be used to execute transparent transactions using a common platform.

Would enterprise companies and organizations be more comfortable paying for open source work through an Open Collective instead of a private transaction with an individual developer?


At DrupalCampNJ, no one rejected the concept of backing a Drupal-related Open Collective. I was able to collect several email addresses which I am going to use to continue persuading and listening to potential backers. My next step is to write a short and persuasive email which hopefully will inspire organizations to back Drupal-related Open Collective.


In the spirit of full transparency, I will publish this email in my next blog post. For now, any feedback or thoughts are always appreciated. Hey, maybe my two anecdotes might have persuaded you to back the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Feb 05 2019
Feb 05

Looking back

Three years ago on Christmas day, I tagged the first alpha of the YAML Form module, which became the Webform module for Drupal 8. Looking back, it has been a great learning experience building and maintaining the Webform module. Looking forward, I want to make sure the Webform module is as stable as possible while still trying to smooth out any rough edges around accessibility and user experience. Everyone should feel that the Webform module is a stable, supported, and maintained part of Drupal's ecosystem of contributed modules. To help organizations and individuals understand what to expect from a stable release of the Webform module, it’s worth defining some general goals.

Setting goals

The goals of this blog post and the overall stability of the Webform module are to…

  • Define the ongoing stable release cycle.

  • Document what to expect from stable releases.

  • Encourage the growth of Webform add-ons and integrations.

Tagging releases

For the past three years, I've been tagging a new release at the beginning of each month. Frequently monthly releases were quickly followed up with a hotfix release to address unexpected regressions. Regressions happen because the Webform module is a feature-rich application with maybe not enough test coverage and definitely not enough eyeballs reviewing the code. Quality assurance is a challenge for open source projects; reviewing code for free is not as much fun as writing it. Even Drupal core needs help with improving the reliability of minor updates.

We need more people reviewing and testing each release.

For example, Webform 8.x-5.1 was released at the beginning of January. It has been followed by Webform 8.x-5.2-beta releases which will last until March, at which point we will transition over to release candidates that will go until April 1st when 8.x-5.2 will be released.

The availability of these beta and release candidates appear on the Webform project page and Drupal's available updates. Hopefully, people will test out these releases, especially for projects that are under active development and would benefit from leveraging the latest features and bug fixes without immediate concerns for stability.

What should people expect from the stable release of the Webform module?

Making changes

Now that the Webform module is stable and covered by the security advisory policy, it's important that we tag new releases anytime there are security issues. Security issues will force any pending beta or release candidates forward into next stable release. Until contribute modules support semantic versioning, this is the only way to move everyone forward to a secure release and stable release.

For me, second to ensuring the security of the Webform, is to ensure that the Webform module is accessible and usable for everyone. Accessibility and usability issues will be fixed as needed with change records documenting any major changes.

Anytime you update the Webform module, please read the release notes and change records.

Finally, the Webform module for Drupal 8 is designed to build amazing forms which can route submission data to any system. Any feature that helps improve this vision will be committed.

For example, I just added the Webform Attachment sub-module which provides webform elements that generate or load files that can be attached to a webform submission and an email handler.

It's important that Webform's ecosystem of add-ons and integrations continues to grow.

Expanding integrations

Even though the Webform module is a feature-rich application, advanced integrations with core and other APIs and applications, including Views, REST, Analysis, and Rules, should continue to be developed as dedicated contribute modules. Integrations with third-party applications also need to be built out as add-on modules. One of Drupal's and Webform's strengths is its flexibility and massive community who make it possible for Drupal applications to be integrated with any system.

Thank you to everyone who has contributed Webform add-ons which integrate with external applications including CiviCRM, Commerce, Druminate, Eloqua, HubSpot,, OpenInbound, iContact, MailChimp, MyEmma, Slack, Stripe, SugarCRM, Salesforce, and more…

Migrating to D8

Lastly, it's time for everyone to start migrating to Drupal 8. Heshan Wanigasooriya (heshanlk) built and supports the Webform migrate module which everyone should use to move their Drupal 6 and 7 webforms and submissions to Drupal 8.

Thank you, Heshan for making everyone's road to Drupal 8 a little smoother.​​

Looking forward

Once we are all migrated to Drupal 8, it will be time to upgrade to Drupal 9. Drupal 9 will provide us with a chance to explore what core improvements make it necessary to create a 6.x branch of the Webform module. Supporting headless webforms and the modernized Drupal admin UI using React could require us to rethink and rework some internal APIs and the form presentation layer.

Getting Involved

There are many ways to get involved with Drupal and the Webform module. And getting involved helps us all.

If you work on a new project which requires the Webform module, please use the latest beta or release candidate during development and testing.

If you create a useful Webform add-on or integration, consider contributing it back to the Drupal community by collaborating on an existing project or creating a new project.

If you launch a Drupal 8 project using the Webform module, consider backing our ongoing effort by joining the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Jan 28 2019
Jan 28

Caring about Webform accessibility

Caring about Webform accessibility was a significant and unexpected personal milestone that happened last year while working towards a stable release of the Webform module for Drupal 8. It’s not that I didn’t care about accessibility, I just never paid attention to it.

Mike Gifford and Andrew Macpherson, Drupal's Accessibility Topic maintainers, helped me understand the importance of accessibility. They also gave me some direction for how to address webform related accessibility issues. This experience led me to do a presentation about Webform Accessibility @ Design4Drupal and to strive to fix accessibility issues in the Webform module. I learned to care about accessibility, but it’s not enough - I still have to ask the question…

Have I done enough to make the Webform module accessible to everyone?

Accessibility can't be neglected

Accessibility has become an important and persistent topic in Open Source communities. I've stated how impressed I am with WordPress's reimaging of its page building user experience, called 'Gutenberg'. At the same time, I was disappointed to see how the WordPress community, specifically how Automattic, addressed accessibility issues related to Gutenberg's user experience. My criticism is based on my sense of the responsibility associated with maintaining an Open Source product used by tens of thousands of websites, and in WordPress' case, is used by over 30% of all websites.

Open Source developers can't neglect or ignore accessibility.

Open Source is about sharing and collaborating on code and ideas with everyone; therefore the result of our collaboration needs to be accessible to everyone.

Drupal's commitment to accessibility

Dries Buytaert, Drupal project lead, recognized the quagmire that was created with WordPress's Gutenberg debacle and posted a call-to-action to the Drupal community titled "Drupal's commitment to accessibility."

Today, I've come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.

-- https://dri.es/drupal-commitment-to-accessibility

The Drupal community has defined an accessibility gate with Web Content Accessibility Guidelines (WCAG) guidelines for releasing new Drupal core features. It’s inspiring to see the Drupal community's commitment to addressing accessibility. Whenever I peek at the Drupal's Accessibility Slack channel, I continually see pings to Andrew Macpherson asking him to review new core features for accessibility issues. Asking one person or even a group of people to review new features for accessibility issues does not scale very well. I’m hesitant to distract Andrew from his Drupal core accessibility responsibilities to help me with evaluating the Webform module for accessibility issues and yet I know it needs to be addressed.

Before the New Year, I was able to chat with Andrew about Drupal's and Webform's accessibility, and I suggested that accessibility should be treated like Drupal's commitment to security. Drupal has a dedicated security team, which displays badges next to stable releases that are covered by Drupal's security advisory policy. Maybe this approach is too extreme, but we need to improve how we make accessibility part of our process when building and maintaining core and contributed projects.

It’s impossible to build a team that can monitor all of Drupal for accessibility issues. My conversation with Andrew led me to suggest that I should try to 'self-certify' and assess the Webform module's accessibility. At the very least I should review, document, and quantify the Webform module's commitment to accessibility. The challenge I faced was…

How to self assess the Webform module's accessibility?

Initially, I found this task to feel daunting until I googled "Accessibility checklists" and found Berkeley's Web Access team's accessibility self-assessment documentation.

Berkeley's Web Access accessibility self-assessment

Accessibility is Usability!!!

-- https://webaccess.berkeley.edu/home

This statement from Berkeley's Web Access homepage is brilliant because it transitions everyone's acknowledgment that usability is a key part of a website's user experience and makes us realize that accessibility is just as important. The Berkeley Web Access team has put a significant amount of thought and passion into these resources.

Berkeley's Web Access site is a comprehensive, up-to-date resource for beginners and experts. There are resources discussing what is a screenreader, what does "keyboard-only" mean? and tips and how tos. They even link to Drupal's accessibility statement. What spoke to me directly was their self-assessment section with a DIY accessibility checklist.

Berkley's DIY Accessibility for Developers Google Sheet is precisely the tool I was looking for to help me take a crack at self-assessing the Webform module's accessibility

Performing the Webform module's DIY Accessibility Audit

To properly self-assess the Webform module's accessibility, it helps to establish some goals. My accessibility self-audit goals are to…

  • Develop a process for auditing the Webform module's accessibility

  • Document and remediate any Webform or Drupal accessibility issues

  • Define a benchmark for the Webform module's accessibility

My process is to fill out the DIY Accessibility Audit spreadsheet's action items AS-IS and avoid making any changes to overall spreadsheet architecture or recommendations. I decided to use WebAIM's WCAG 2 Checklist with my favorite accessibility evaluation tool, the WAVE extension for Chrome. I also wanted to leverage Pa11y, an automated and command-line testing tools. All new accessibility issues would be documented on Drupal.org via Issue #3026393: [meta] Self-assess the Webform module for Drupal 8's accessibility. The completed spreadsheet will define a benchmark for the Webform module's accessibility.

I also think it’s important to note that all aspects of the Webform module's accessibility are being reviewed and assessed, not just the generated public-facing forms. The form builder and administrative user interfaces must also be accessible to everyone. Since the Webform module is built on top of Drupal's Form API, some accessibility issues may be coming from Drupal core. Therefore, I’m also going to track and document related Drupal core accessibility issues.

Here are results from the Webform module's DIY Accessibility Audit

When I began reviewing and filling in the DIY Accessibility for Developers spreadsheet, I had a misconception that I’d be able to share some statistical results that quantify the Webform module's accessibility. The first page of the spreadsheet does include the number of issues and their statuses. I don't feel saying X issues exist with X fixed and X remaining portrays a complete picture. The experience of filling out this spreadsheet did give me an understanding of what is required to make a user experience like the Webform module accessible.

Developers need to start reviewing their project's user experience through different perspectives. To understand accessibility, developers need to navigate the project's UX using just the keyboard and recognize that every piece of content and the visible widget will be read aloud by a screen reader.

I found that the combination of reviewing the WCAG guidelines and comparing the results from two automated tools, WAVE and Pa11y, helped me to see any immediate problems. Listing out individual WCAG guidelines with Webform and Drupal specific notes helped me apprehend the Webform module's accessibility. I did find and remedy a few accessibility issues, which were all related to the proper labeling of form inputs with appropriate contextual information, which would be read aloud via a screen reader.

The Web Content Accessibility Guidelines (WCAG) can feel overwhelming but when I approached them using WebAIM's WCAG 2 Checklist, it was easy to just read through them and determine which guidelines apply to the Webform module. Collaborating and iteratively defining an accessibility checklist with recommended accessibility testing tools for Drupal core and contribute projects would help ensure the accessibility is part of our Drupal communities process. Some of this discussion is already happening via Issue #2857808: Automating accessibility checks

Self-assessment can improve Drupal's accessibility

Self-assessment is one of many tools and approaches to improving Drupal's accessibility. We recognize security and automated testing as part of our process and visibly on every project page. Shouldn't accessibility be treated the same way?

Personally, I take a lot of pride in knowing the Webform module is one the most accessible form builders on the market. This is something I want to promote to anyone evaluating the Webform module and Drupal.

Promoting the Webform module's accessibility

To truly and publically define the Webform's accessibility benchmark, I decided to add the below callout to the Webform module's project which links to the completed spreadsheet and this blog post.

The Webform module is committed to being accessible to everyone.

The Webform module is committed to being accessible to everyone.

Contributing and funding Webform accessibility

Improving the Webform module's and Drupal's accessibility requires an ongoing effort. Every minor release of Webform and Drupal should include accessibility improvements. If you have the time and resources, please get involved in the Drupal and the Webform module's issue queue. Organizations that rely on the Webform module should consider backing or donating the Webform module's Open Collective. Backing the Webform module's Open Collective will help us improve accessibility and encourage the overall growth and support of the Webform module.

Final thoughts

I like Berkeley's Web Access statement that "Accessibility is Usability!!!" so much, I decided to play with these words and came up with…

Open Source is Accessibility!!!

This statement plays with multiple meaning of accessibility because Open Source is built on the idea that the software's source code should be accessible to everyone. It’s now time for our software to be accessible to everyone.

Everyone needs to care accessibility and your opinion matters. Asking people to self-access their code might be asking too much. At the same time, I'm proud of the accessibility bullet point I have added to my resume skills. Striving to include everyone and anyone is never a bad idea. For me, being an Open Source developer is more than just writing code, it’s about working with a diverse and inclusive community of people, and doing my level best to make sure everyone is acknowledged, heard, seen and considered. We’re all individuals but we’re also all part of the big picture.

What do you think about encouraging Drupal core and contrib developers to self-assess their code and projects?

Please post your thought below and consider backing or donating to the Webform module's Open Collective.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Jan 15 2019
Jan 15

Open Source

Open source and me

For the past two years, I have been blogging about my experience building and maintaining the Webform module for Drupal 8 and have had some lively discussions about them all. As the Webform module moved from beta or release candidates, I shared my experience in two posts titled Webform 8.x-5.x: Where Do We Come From? What Are We? Where Are We Going? and Webform, Drupal, and Open Source...Where are we going?. Throughout my blog posts, the question persists…

How is open source sustainable?

Open source and organizations

In 2018, open source has become a success story, particularly for large organizations. As someone who has been building websites since Microsoft Internet Explorer 4.0 (1997), I see the fact that Microsoft is going to use the open source Chromium rendering engine as an amazing achievement for open source and even Microsoft. Microsoft has transformed from calling Linux a cancer to fully embracing open source collaboration.

Open source allows organizations to make a collaborative investment that provides them with a large technical return.

Organizations sponsor open source, however, the work is done by individual developers who may work for an organization or independently within the open source community.

What about individual software developers who contribute to open source? At what point do we recognize their part?

Open source and individuals

I recently wrote about Why I am one of the top contributors to Drupal? which explains my motives for my contribution to Drupal and my commitment to maintaining the Webform Module for Drupal 8 for the foreseeable future. One key reason behind my contribution is…

Open source allows individuals to share their passion with a collaborative community which improves their professional profile/resume.

The lone software developer has become a thing of the past. Modern software is a collective and collaborative process. Many software developers’ first experience with software collaboration is when using or contributing to an open source project. Ideally, the lone software developer becomes a member of the open source software community.

That said, building, maintaining, and sustaining collaborative communities where organizations and individuals work together is challenging.

Open Source and community

Growing, nurturing and building anything comes with a set of challenges and difficulties - open source projects are no exception. And this is where structure comes in. Structure, a system, a framework - whatever you want to call it - helps us gauge where we’ve been, where we’re going and where we want to be. Communities need to have some system of governance and sustainability. Open source projects are built by a loosely knit community of developers working together and making decisions.

The most common decision making roles in open source is the 'maintainer' because they help make sure a project continues to grow and work.

Maintainers need to be able to maintain their projects. Projects need to be maintained.

Open source and sustainability

The discussion around open source sustainability is ongoing. Danny Crichton at TechCrunch recently wrote a comprehensive essay about the current state of open source sustainability. It is a worthwhile read with useful background information and references.

There are several approaches to funding/supporting open source developers. To me, the most appealing approach is Open Collective because it is exploring how to collect and distribute funds for an open source project in a completely transparent way.

Open source software is typically created using full transparency. The problem of open source sustainability may be best solved using full transparency.

Open Collective

Open source and Open Collective

Open Collective is a platform for global collaborations to transparently collect and distribute funds.

Open Collective is trying to solve the much larger issue of global collaboration, and open source is one type of collaboration. Besides an open source project, an Open Collective can be set up for a meetup, a political group, or even a Drupal Camp.

Persuading people to contribute funds to an Open Collective requires a mix of marketing, messaging and incentives.

Open Collective and incentives

The strongest incentive to get anyone to do something is to provide a tangible result. Tangible results can be elusive when fixing a bug or upgrading some code. Finding the right messaging and incentives requires experimentation. Incentives should help people get the most out of the software. Incentives could be bug fixes, feature requests, support requests, documentation. If these experiments are successful with organizations and individuals backing and funding an Open Collective; the Open Collective will face its next challenge which is spending the money.

Once a project has money, it is up to the maintainers of that community to decide how to spend it.

-- https://techcrunch.com/2018/06/23/open-source-sustainability/ 

Open Collective and money

It is doubtful that most open source maintainers and contributors can be fully compensated for their late night hours and weekends contributing code, design, documentation, project management, and other expertise to an open source project.

We need to figure how to best spend the money in ways that provide a high return.

In the Drupal, we like to say “Come for the code, stay for the community.” Communities require infrastructure to work and grow. Reinvesting an Open Collective's funds to grow a project's community could give everyone involved some incentive. For example, we could use Open Collective funds to make it more financially feasible for a project's maintainers to speak at events. Another concrete reinvestment of funds is paying for code sprints.

Open Collective is providing a tool which helps improves open source sustainability. It is up to each project's maintainer to determine how to use this tool and collected funds.

How can Open Collective directly benefit the Webform module and the Drupal community?


Open Collective and Webform

The goal of this blog post is to initiate the conversation around leveraging Open Collection within the Drupal community. Developing and refining the marketing and messaging for the Webform module's Open Collective is going to be an interactive process with some experimentation.

Webform and marketing

The success of the Webforms' Open Collective is going to hinge on the Webform module's project page on Drupal.org, the Webform module's page on Open Collective, and some callouts in the documentation, videos and maybe in the Webform module's user interface

Webform and messaging

After three years of working heavily on an open source project, I strongly feel that the most important message to new and even old people in the open source community is…

Everyone is welcome and we are here to help.

Gradually within the Webform module's Open Collective, we need to figure out how to talk to the consumer of the software by…

Communicating the value of contributing and providing incentives for people to contribute.

Webform and incentives

Support is the most immediate incentive to get people to pay for open source software. WordPress' plugin ecosystem openly asks and sometimes requires people to pay for support licenses. I never want to force or trick a user to pay for support. The Drupal community is passionately against paid modules. Nevertheless, it’s important to communicate to people that supporting an Open Collective will help support the Webform module and the Drupal community. There is no doubt they go hand in hand.

Frankly, I already escalate issue queue tickets created by people and organizations who are active contributors or sponsors in the Drupal community, especially if they are members of the Drupal Association. BTW, I also welcome and escalate tickets created by new members of the Drupal community. I have not publicly documented this policy, but it is worth asking "Should we be providing free software with free support?"

Webform and money

How the funds in Webform module's Open Collective are being distributed is tricky but not impossible. Initially focusing on reinvesting any funds back into the Webform and Drupal community and the software is a fair and reasonable approach. The collected funds should only be spent on event/speaking related costs and direct improvements to the Webform module's user experience, accessibility, and marketing.

Reinvesting funds for marketing might be the only controversial expense. I am going to tread lightly with spending money on marketing, but the Webform module needs a logo, maybe a better slide deck, and some SEO to compete with the 100's of other form builders on the market. BTW, Drupal's community is so awesome I would not be surprised if someone contributed a logo to the Webform module.

Webform and me

I am not going to get rich from the Webform module. I am incredibly fortunate to have steady consulting work, which allows me to contribute my time to the Webform module. The Webform module is a professional and intellectual challenge for me. The sustainability of the Webform module is part of this challenge.

What fascinates me most about the challenge of open source sustainability is the scale that our open source projects are benefiting everyone including large organizations. Large organizations have realized that they can tap in the power of open source software and its communities.

Open source needs to push back on organizations and ask them to give back.

Us and open source

“The culture of our community should be one that gives back and supports community projects with all that they can: whether with employee time or funding. Instead of just embracing the consumption of open source and ignoring the cost, we should take responsibility for its sustainability."

-- Henry Zhu of Babel

Open source is about us. Us is anyone that uses open source projects. Sometimes, we forget that even the individual or organization that uses the software without contributing back to open source are still peripheral members of our community. We need to explore how we are marketing open source projects, think about our messaging and provide some incentives to welcome and encourage everyone to get involved.

Join the Webform module's Open Collective

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Dec 12 2018
Dec 12

Webforms in Drupal 8 are configuration entities, which means that they are exportable to YAML files and this makes it easy to transfer a webform from one server environment to another. Generally, anything that defines functionality or behavior in Drupal 8 is stored as simple configuration or a configuration entity. For example, fields, views, and roles are stored as configuration entities. Things that are considered 'content' are stored in the database as content entities. Content entities include nodes, comments, taxonomy terms, users, and also webform submissions.

Configuration is exportable as YAML.
Content is stored in the database.

Managing Configuration

The core concept behind Drupal's configuration management is you can export and import how a website is configured (aka how it works) from one environment to another environment. For example, we might want to copy the configuration from your staging server to your production server. Drupal 8 has initially taken the approach that all configuration from one environment needs to be moved to the new environment. The problem is that…

The imported configuration will clobber (aka replace) any existing configuration

In the case of webforms and blocks, this is a major issue because site builders are continually updating these config entities on a production website. The Drupal community is aware of this problem - they have provided some solutions and are actively working to fix this challenge/issue in a future release of Drupal.

Improving Configuration Management

Below is a summary of these three modules.

The Config Filter module provides an API for controlling what configuration is imported or not imported for different environments.

The Configuration Split module allows defining sets of configuration that will get exported for different environments.

The Config Ignore module allows specified configuration not to be imported (aka ignored) and overwritten.

Geert van Dort's recipe for Configuration Management

Geert van Dort has written a great resource documenting how to exclude config from configuration management in Drupal 8 and he uses Webforms as his example. Geert van Dort's article is a must-read.

There is one somewhat obvious configuration management gotcha that I have not seen fully documented.

The importing of outdated configuration gotcha

In the Webform issue queue, I am repeatedly seeing tickets related to exported webform config that have not been properly updated. For example, someone exports a Webform from 8.x-5.0-rc10, updates the Webform module to 8.x-5.0-rc26, runs the database/config updates, and then imports the Webform configuration from 8.x-5.0-rc10, which is missing any new configuration properties and changes from 8.x-5.0-rc26. Usually, I am able to pinpoint the missing update hook and suggest that someone runs the missing update hook using a drush command like…

drush php-eval 'module_load_include('install', 'webform'); webform_update_8144()';​

How to prevent the outdated configuration import gotcha

Good configuration management comes down to deciding on an approach and following it.

For me, the above concept was the most important takeaway from Michael Anello's Drupal 8 Configuration System Basics.

The solution to prevent the outdated configuration gotcha is to define a process and follow it. Below is a general outline of the steps required to make sure your exported configuration is always up-to-date

On your local or development environment:

When deploying core and contrib module updates:

I have deliberately avoided including what specific mechanism you should be using for updating your site, which generally should be a combination of GIT, Composer, and Drush because the most important step is…

Make sure when you update Drupal core and contrib modules, your exported configuration has also been updated.

The Distribution Configuration Gotcha

Distributions are full copies of Drupal that include Drupal Core, along with additional software such as themes, modules, libraries ​and installation profiles.

Distributions include predefined configuration files, which can quickly become out-of-sync with the distribution's modules. For example, a distribution's exported configuration could be expecting an older version of the Webform module. It is the distribution maintainer's responsibility to keep the configuration up-to-date which is challenging because they have to do a full installation of the distribution, update the distribution's modules and then export the updated configuration. This is a very tedious process.

One immediate thing that a module or theme maintainer can do to help distribution maintainers is to keep change records and tag any changes that might impact a distribution. Another best practice is to try to keep configuration breaking changes to a minimum.

Webform specific configuration management tools

Exporting webform configuration

The fact that an entire Webform is exportable into one file has made it possible to create feature and element specific test webforms, which I use during automated testing. Currently, there are over 200+ test webforms included in the Webform's test modules. The Webform module provides an 'Export' tab which allows you to easily and quickly export any webform.

Webform Export Tab

Webform Export Tab

If you find an issue with a webform, the best way to get help is to isolate the problem to a simple example webform, export it, and then upload it to the Webform issue queue.

Tidying exported YAML

Another minor enhancement you will see in exported Webform is that the multiline strings in the YAML file are formatted in a more readable form. To learn more, see Issue #2844452: Export configuration YAML strings as multiline. If you need your exported YAML configuration file in a slightly more readable format you can also use the Webform's tidy Drush command.

Repairing admin configuration and webform settings

If you happen upon some webform configuration that is outdated, you can run the drush webform:repair command or click the 'Repair configuration' via the admin UI under that 'Advanced' configuration tab (/admin/structure/webform/config/advanced)

Repair Webform Configuration

Repair Webform Configuration

The future of configuration management

I have been using Drupal's configuration management since early alpha releases of Drupal 8 when configuration was not even stored in the database. The Config Filter, Configuration Split, and Config Ignore trifecta of contributed modules show how the Drupal community can work together to fix some challenging issues, paving the way for solutions to make their way in Drupal core.

The concept that we can quickly export an entire Webform into one shareable file is awesome and has made my life exponentially easier in maintaining the Webform module for Drupal 8.

The proposal for the Configuration Management 2.0 initiative is comprehensive and exciting. For example, if the Webform module could hook into the configuration import process, we should be able to repair outdated configuration as it is imported. For now, I want to say thanks to everyone involved in Drupal's Configuration Management Initiative.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Nov 27 2018
Nov 27

Attending Drupal Events grows our community

In my last blog post about Talking about Advanced Webforms and Showing Code, I mentioned my presentation needed work and I needed practice. At DrupalCamp Atlanta, I was able to do just that. I delivered my 'Advanced Webform' presentation and received some very valuable constructive criticism on how to simplify and improve my slide deck from Michael Anello (ultimike).

At DrupalCamps I enjoy presenting and sharing my passion for the Webform module with the Drupal community. I also value hearing and seeing what other people are doing with Drupal. In Atlanta, listening to Jesus Manuel Olivas (jmolivas) passionately talking about using GatsbyJS with Headless Drupal was inspiring plus I want to mention that this approach represents a huge paradigm shift for all enterprise content management systems. Besides hearing about the latest and greatest technologies at DrupalCamp Atlanta, I also learned how much work it is to organize a DrupalCamp.

The organizers of DrupalCamp Atlanta did a fantastic job. Kaleem Clarkson (kclarkson), one of the camp's organizers, posted a call to action for organizations using Drupal to sponsor an event

Sponsoring an event

Kaleem's post titled, Sponsoring a DrupalCamp is Not About the Return on Investment (ROI), reminds everyone of the importance and value of sponsoring a camp. He also acknowledges that some companies focus and roles are shifting within the Drupal community. I think the most important question/situation Kaleem addresses is…

If Drupal is the "enterprise solution", what does this mean to our community and camps?

I am 100% okay with Drupal being an enterprise solution. Large organizations are using Open Source and they need an enterprise content management solution. Enterprise companies using Drupal need to train and support their employees; DrupalCamps are a great place to start.

Companies should sponsor Drupal events and the community

Kaleem makes solid arguments as to why a company should sponsor an event, which includes visibility, credibility, and collegiality. Companies have to keep track of their ROI, so it is important to ask what does a company gets and wants from Drupal event. The best way to get a company to open their wallets is to show them some results. Drupal is the result of companies and people sharing time and money to build something outstanding. We need to entice new companies to sponsor event and sprints.

Sponsor a sprint

Code sprints happen at every Drupal event. Sometimes there are organized collaborations with a dedicated time and place and other times peoples are committing last-minute patches and tagging a new release before a presentation. Events and sprints tend to go hand-in-hand, but it’s worth emphasizing that code sprints produce tangible results.

I always get nervous before I get up in front of a large audience, so instead of biting my nails, I work on fixing a bug or writing some cool feature enhancement to the Webform module. I have recognized this pattern, so now when I go to camps I have a personal Webform code sprint agenda.

At Design4Drupal, I started caring about and fix accessibility issues. At DrupalCamp Atlanta, I finally fixed all the lingering issues with conditional logic and even created a ticket for a stable release of webform. My point here is that things happen at Drupal events and sprints, sponsoring companies help make these things happen.

Companies should help sponsor and provide content and speakers for Drupal events.

Sponsor a speaker

Drupal events can’t happen if there is no one willing or able to get up at the podium and talk about Drupal. Good presentations and keynotes can inspire and even shift the direction of the entire Drupal community.

Who is speaking at Drupal event

There are generally two types of speakers at a Drupal event, the first is someone representing their organization/employer, and the other is someone representing their personal and professional interest. Both types are valuable and add to the collective discussion and evolution of Drupal and its community. Some speakers, including myself, represent an organization and their personal and professional interest.

Organizations need to encourage their employees to speak and contribute to Drupal. Everyone benefits when an employee participates in a Drupal event. Personally, learning how to speak publically is my biggest personal and professional accomplishment while working on the Webform module. Having my recorded session available online allows potential employers and clients to know that I am not afraid to get up in front of a large group of people and talk about Drupal.

Organizations also benefit from having employees promote services, hosting, products, and ideas being built around Drupal. Of course, we don't want DrupalCamps to become paid infomercials but these events provide opportunities for organizations and developers to collectively help steer the direction of Drupal.

Supporting individual speakers

There are a bunch of people in the Drupal community who are the maintainers of specific modules or APIs. For example, I am the maintainer of the Webform module for Drupal 8. I travel on my own dime to events and talk about the Webform module and related topics. The only limitation I run into with traveling to events is the cost per event, which for anything outside of the New York tri-state area is around $750 to $1,000 dollars. I am not exactly sure if people should be paid to speak at events, however, I know first hand that travel expenses limit where and how often I speak at Drupal Events.

Should organizations sponsor speakers?

There are three immediate benefits to sponsoring a speaker.

First, you get the subject matter expert to come to your community and share their ideas. For example, as a community, we need people passionately talking about using GatsbyJS and Headless Drupal at as many Drupal events as possible.

Second, you get to pick the brains of subject matter experts for ideas. I know that if an organization paid for my travel expenses, I would have no hesitation spending a few hours helping them review and understand how they can best leverage the Webform module and Drupal 8 for their client's projects and needs.

Finally, helping to offset some of the costs for someone who is sharing their ideas and time with the Drupal community is a great way to say thanks.

Proposing that a speaker should be sponsored/paid to talk at a Drupal event is going to require some more thought and work. There is one aspect to all our Drupal events which should be paid for… the red button.

Sponsor the red button

Kevin Thull has been recognized for his ongoing contribution to Drupal community which is making sure our presentations are recorded and shared online. I will let everyone in on a little somewhat known secret to getting your session proposal accepted at a DrupalCon - you need prior speaking experience. Kevin's session recordings from DrupalCamps are used and vital to the DrupalCon speaker selection process.

Let's not forget that Kevin's 600-plus session recording helps to share information with people that could not attend a DrupalCamp. We have all faced the quagmire of trying to understand how a module or Drupalism is supposed to work and have watched a recorded presentation to get over this challenging hump.

Kevin started a GoFundMe campaign for "paying for food and commuter costs out of my own pocket, which average around $350 per camp." He is really close to his goal of $5000. We should all contribute to making sure he reaches this goal and then exceeds it.

Click the damned button!

Click the damned button!

Final thoughts

The Drupal community is massive, and we collaborate and solve some amazingly challenging problems. The challenge of sustainability is only going to be addressed when we figure out our economy around Open Source software. Realistically, the recent high profile acquisitions of RedHat and GitHub is tied to these companies’ reliance on software-as-a-service (SaaS) and cloud computing. Both companies contribute heavily to Open Source. These acquisitions are significant to ongoing growth and success of Open Source but these are large transactions.

Drupal and Open Source community still need to figure out what smaller transactions are required in order to help grow and sustain our communities. For now, giving $10, $20, or $50 to help Kevin Thull continue to record our presentations and share our ideas and passions is a good start.

Support the Red Button

What are your thoughts?

I am sure Kevin and I are not alone in trying to figure out how to offset the costs of presenting at and recording DrupalCamps. Conversely, there are also organizations who are also figuring how to start or continue support DrupalCamps and Meetups. Please post your thought below and on Drupal.org

via Issue #3012321: Governance Taskforce Recommendation "Provide Greater Support For In-Person.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Nov 05 2018
Nov 05

For the past two North American DrupalCons, my presentations have focused on introducing people to the Webform module for Drupal 8. First and foremost, it’s important that people understand the primary use case behind the Webform module, within Drupal's ecosystem of contributed modules, which is to…

Build a form which collects submission data

The other important message I include in all my presentations is…

The Webform module provides all the features expected from an enterprise proprietary form builder combined with the flexibility and openness of Drupal.

Over the past two years, between presentations, screencasts, blog posts, and providing support, the Webform module has become very robust and feature complete. Only experienced and advanced Drupal developers have been able to fully tap into the flexibility and openness of the Webform module.

The flexibility and openness of Drupal

Drupal's 'openness' stems from the fact that the software is Open Source; every line of code is freely shared. The Drupal's community's collaborative nature does more than just 'share code'. We share our ideas, failures, successes, and more. This collaboration leads to an incredible amount of flexibility. In the massive world of Content Management Systems, 'flexibility' is what makes Drupal stand apart from its competitors.

Most blog posts and promotional material about Drupal's flexibility reasonably omits the fact that Drupal has a steep learning curve. Developers new to Drupal struggle to understand entities, plugins, hooks, event subscribers, derivatives, and more until they have an ‘Aha’ moment where they realize how ridiculously flexible Drupal is.

The Webform module also has a steep learning curve

The Webform module's user experience focuses on making it easy for people to start building fairly robust forms quickly, including the ability to edit the YAML source behind a form. This gives users a starting point to understanding Drupal's render and form APIs. As soon as someone decides to peek at the Webform module's entities and plugins, they begin to see the steep learning curve that is Drupal.

Fortunately, most Webform related APIs which include entities, plugins, and theming follow existing patterns and best practices provided by Drupal core. There are some Webform-specific use cases around access controls, external libraries, and advanced form elements and composites, which require some unique solutions. These APIs and design patterns can become overwhelming making it difficult to know where to get started when it comes to customizing and extending the Webform module.

It is time to start talking about advanced webforms.

Advanced Webforms @ DrupaCon Seattle 2019

Drupal Seattle 2019 - April 8-12

Drupal Seattle 2019 - April 8-12

DrupalCon Seattle is scheduled to take place in April 2019, but session proposals are closed. There are a lot of changes coming for DrupalCon Seattle 2019. The most immediate one affecting presenters is that proposals are limited to either a 30-minute session or a 90-minute training. I understanding this change because a well-planned and focused topic can be addressed in 30 minutes while training someone requires more time. I’m happy to say that my proposal for a 90-minute Advanced Webform presentation was accepted. Now I need to start putting together the session outline and materials

Talking about advanced ​webforms for 90 minutes is going to exhausting so I promise everyone attending there will be a break.

I’ve decided to break up this presentation into two parts. The first part is going to be an advanced demo. I’ll be walking through how to build an event registration system and maybe an application evaluation system. During these demos, we’re going to explore more some of the Webform's modules advanced features and use-cases.

The second part of the presentation is going to be a walkthrough the APIs and concepts behind the Webform module.

Topics will include…

  • Creating custom form elements

  • Posting submissions using handlers

  • Altering forms and elements

  • Leveraging API's

  • Writing tests

  • Development tips & tricks

This presentation is going to require a lot of work. Luckily, I have six months to practice my presentation and work out some of the kinks.

Talking about code is hard

Fortunately, there are plenty of DrupalCamps before DrupalCon Seattle where I can rehearse my presentation. Two weeks ago, I presented the second part of my training at BadCamp and learned that scrolling through code while talking is challenging. I struggled with clicking thru PHPStorm's directory trees and showing different interfaces for entities and plugins.

Being able to navigate and understand code is key to climbing Drupal's steep learning curve.

I enjoy giving live Webform demos because I really believe that physically showing people how easy it is to build a form makes them feel more comfortable with getting their hands dirty. Even making mistakes during a live demo helps people see that clicking a wrong button is just part of the process. For me, the most successful and inspiring presentations are the ones where I walk out of the room with a new appreciation of the topic and a new perspective regarding the best way to learn more about the subject matter. My live demo of code at BadCamp did not work great but now I have the opportunity to improve it and I need to…

Figure out how to show the code.

Showing code during a presentation

A few years ago, my friend and coworker, Eric Sod (esod), did an excellent technical presentation about Drupal Console, which is a command line tool used to generate boilerplate code, interact with and debug Drupal. He figured out how to get past the challenge of talking and showing people how to use a command line tool. He did this by recording each console command. It was an inspiring presentation because he calmly stood in front of the room and explained everything that was happening in his recorded demo. He didn’t have to worry about misspelling a command.

Eric's approach to pre-recording challenging demos may be the solution that I am looking for. I am going to test it out at DrupalCamp Atlanta.

Going on the road and practicing this presentation

The biggest takeaway from this blog post should be:

The road to presenting at DrupalCon requires a lot of practice.

If your session proposal did not get accepted for this year's DrupalCon, keep on practicing. Make sure to record your presentations, even if it is a private screencast so that you can share this recording with next year's DrupalCon Minneapolis session selection committee. They want to know that you are comfortable getting up in front of a sizeable and curious audience.

There are plenty of upcoming local meetups and DrupalCamps where you can present..

Below are the DrupalCamps I am hoping to speak at before DrupalCon Seattle.

I hope to see you at a local DrupalCamp or we can catch up at DrupalCon Seattle. And if you have any suggestions on how to improve my presentation, for the next six months I’ll be working on it and I’m all ears…

If you want to know where I am speaking next, please subscribe to my blog below or follow me on Twitter.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Oct 17 2018
Oct 17

In my last blog post, I explained, "Why I am one of the top contributors to Drupal?" and examined my ongoing contribution to the Webform module for Drupal 8. My post was inspired by Dries Buytaert's annual who sponsors Drupal development post. Now I want to dig into that list of who’s and acknowledge other individuals contributing to Drupal.

Let's explore some of the top contributors to Drupal.

I am deliberately limiting the discussed contributors to people that I have had minimal or no direct interaction with online or in-person. I want to explore their contributions based on their online presence versus directly interviewing them.

Every contributor's online presences tell a story

The Drunken Monkey

I genuinely value Drunken Monkey's contribution to Drupal's Search API module.

This module provides a framework for easily creating searches on any entity known to Drupal, using any kind of search engine.

We rarely appreciate an API module until we have to start using them and diving into the code. The Search API module for Drupal 8 is a magnificent example of great code which conquers one of the hardest challenges in programming: naming things.

For a recent project, I was diving into Search API's code, and Drunkey Monkey helped me out when I discovered Issue #2907518: Breakup tracking of content entities into smaller chunks to prevent memory limit issue. For the developers out there, if you read through the issue to the final patch, you will notice that Drunken Monkey manages to even improve some APIs while fixing the problem.

The Search API Guy

The first place to understand who is who in the Drupal community is people's user profiles. The most immediate thing that stands out about Drunkey Monkey is that he is…

The Search API Guy

This statement is something I can relate to because I have also promoted myself as "The Webform Guy for Drupal 8". I learned from maintainers like Drunken Monkey that becoming the person behind a Drupal project is a valued role in the Drupal community. On a related note, Thomas and I have both been members of Drupal community for 10+ years and this fact indicates that it can take time to find one's niche in the Drupal community.

Drunken Monkey is Thomas Seidl

Thomat Seidle (drunken monkey)

Thomat Seidle (drunken monkey)

Thomas Seidl is a developer from Vienna, Austria, and has been involved in Drupal and search since 2007.

-- https://drunkenmonkey.at

Thomas is the man behind the code and his personal website promotes his contribution to Search API and offers his paid support services. His promotion of paid support directly contributed to his sponsored work porting Search API to Drupal 8.

Acquia generously agreed to fund all available time for both Joris Vercammen (borisson_) and me in December and January to work on this port and related modules

-- https://Drunken Monkey.at/blog/search_api_d8_alpha_12

Thomas was a student who became a mentor

Thomas' code and ability to maintain something as complex and important as Search API hints that he has professional training. Thomas has a Master's degree in Computer Science and a Bachelor in Engineering Physics.

Being mentored and mentoring is the not so secret sauce to Open Source. Thomas has some experience doing both because he participated as a student in four Google Summers of Code and twice as a mentor.

Not surprising, Google Summer of Code has helped many other people begin their Drupal careers /experience.

What was Thomas's first foray into the world of Drupal?

Thomas' first post and patch to Drupal

Looking at someone's very first post on Drupal.org can lead to many conclusions or thoughts. Some people test the Drupal community's waters by asking a simple question. Others post an issue and then disappear. Then there is someone like Thomas who hits the ground running. His very first post on Drupal.org from 2007 is…

Issue #176124: Fatal error when running all tests

I started to smile when I read this issue because first off, Thomas found an existing ticket that was impacting him and then proceeded to provide a patch. It’s also worth noting that he was fortunate to have two active Drupal contributors, Rok Žlender and Peter Wolanin, in his sphere.

Finally, and definitely worth noting, Thomas, the Search API guy, had many individuals and organizations helping him. He highlights and acknowledges them on the Search API project page. Giving props to the collaborating irons in the fire, both big and small, demonstrates a wholly appreciative understanding of what this is all about.

“Our thanks goes to Acquia, MD Systems, Intracto and a few smaller donors and clients for financial support. Thanks as well to the large number of people who helped with development tasks and patches.”

-- Thomas Seidl

Who is volkswagenchick?

AnyJune Hineline (volkswagenchick)

AnyJune Hineline (volkswagenchick)

Let's immediately acknowledge that 'volkswagenchick' is a pretty identifiable username. Appending the word 'chick' to one's username allows one to stand out in the sea of geeky names like 'optimusprime' and 'frodo'. I am not sure if AmyJune Hineline is German, but I was able to learn that she like Volkswagens and lives in the US.

Volkswagenchick is AmyJune Hineline

AmyJune's profile on Drupal.org is fairly simple but links to a wealth of resources. Immediately three things stand out on AmyJune's Drupal.org profile - she is the Community Lead and a Drupal Site builder with Hook 42 and has been a member of Drupal.org for less than three years.

Wow, three years into her Drupal career and AmyJune is one of the top contributors to Drupal.

Hook 42 contributes to Drupal

After reading and learning about Hook 42, I am tempted to do a dedicated follow-up post exploring the organizations that contribute to Drupal but for the moment, I think Hook 42 deserves credit and gratitude for their employee’s role and contribution to the Drupal community. And I’m not the only one who seems to think so - Hook 42 is making a major contribution to Drupal and does appear in Dries blog post.

Our organization is not only using Drupal, but also contributes back to the community and to the project by writing modules and themes, participating in forums, presenting at conferences, organizing Drupal events, and more.

-- https://www.hook42.com/team

AmyJune has a mentor

Besides having a great employer, AmyJune found one of the best instructors/mentors in the Drupal Community: Mike Anello (ultimike). AmyJune credits Mike’s Drupal Career Online for helping to get her started with her career in the Drupal community. A while back, I talked about Mike's Drupal Career Online.

I’m specifically intrigued by his Drupal Career Online for individuals; It's a 12-week, instructor-led online course that goes deep and broad into the technology, community engagement, and hands-on exercises to give you a rock-solid foundation for a successful Drupal career. Mike's helping Drupal newbies become Drupal rockstars. He’s helping to grow the Drupal community by inspiring and helping individual developers to join our community. "He is helping the little guy in our community."

-- https://www.jrockowitz.com/blog/little-guy

AmyJune just proved that Mike is helping Drupal newbies become Drupal rockstars.

AmyJune has an amazing story

AmyJune is a prolific blogger who has chronicled her journey.

Drupal was the feel good adventure I needed to move on. Being open-source and free, it allows more organizations, like nonprofits and higher-eds to have custom websites built to their specific needs while maintaining smaller budgets.

-- From Nurse to Drupal Programmer: an Intern's Journey

Reading AmyJune's blog posts and understanding her journey makes it clear to me that some of the top contributors to Drupal are not just coders but people who are an integral part of the Drupal community.

AmyJune's first issue on Drupal.org

Right out of the gate, AmyJune posted a very simple constructive comment:

Issue #2450191: Be more specific when listing dependencies so that `drush en office_hours` can work

AmyJune received a perfect response from John Voskuilen (johnv) the Office Hours maintainer.

Thanks for the feedback. Hope you enjoy this module.

Little did John know that he was also helping AmyJune on her journey to becoming a leader in the Drupal Community. Ironically and related to this first issue, AmyJune went on contribute many patches which improved the README.txt files for dozens of contributed modules.

What does IMCE stand for?

IMCE is an image/file uploader and browser that supports personal directories and quota.



Nowhere on the IMCE project page does it state what the heck does IMCE stands for. I am not even sure it is an acronym. Even with Drupal's amazing improvements to media and file handling, IMCE has continued to be one of Drupal's most installed modules.

Besides the module's name, the even bigger mystery is the project's maintainer, ufku. I would like to thank them for saving my butt on numerous occasions where the IMCE provided the exact functionality needed to fulfill a project's requirement. Ufku does not seem interested in racking up commit credits, but I’m intrigued to explore who they are and say thanks

Who is Ufku? The Unknown Drupaler



Ufku has been maintaining IMCE for over 12 years. They have been a member of the Drupal community for 14 years. Ufku's user profile is sparse and their personal website just includes an IMCE demo with README files. I even desperately checked ufku.com in the whois database and there is no identifying information

Ufku has made an awesome contribution to Drupal for many years and does not seek any acknowledgment.

Let's just say thanks to Ufku

Clearly, Ufku's commitment to IMCE shows that they value Drupal. I hope that Ufku's tremendous and continuous work on IMCE is on their resume because it demonstrates a fantastic commitment and contribution to Drupal and Open Source.

Ufku whoever you are, I want to say thanks.

Ufku first post on Drupal.org

I am hesitant to pry through Ufku posts on Drupal.org because clearly, they want to remain somewhat anonymous.

Ufhu's first forum post, one-click language switch without a module (drp-4.5), shows that from day one they wanted to share some code with the Drupal community.

There are so many more contributor stories out there

Every contributor to Drupal has a story and there are many ways to explore them. Personally, I always start with people's Drupal.org profile and if I get curious enough, I start hunting for videos and podcasts.

Hear more about AmyJune and Thomas

Below are some links to learn more about AmyJune and Thomas.

AmyJune Hineline (volkswagenchick):

Thomas Seidl (drunken monkey):

For now, ufku can be called 'The Unknown Drupaler'.

Learn more about Drupal contributors

Below are some blogs and podcasts where you can learn more about the people who contribute to Drupal:

Saying Thanks

I hope the biggest lesson you can take away from this blog post is…

Behind every line of Open Source code is a person or organization. Since the code and its history is Open Source, you can find out who that person is and thank them.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Oct 01 2018
Oct 01

Who sponsors Drupal development?

We know who contributes

A few weeks ago, Dries Buytaert published his annual who sponsors Drupal development. His report acknowledges individual and organization contributions and what projects they are supporting. This report provides a high-level overview of who contributing in the Drupal community. There are some old names on this list and some new names.

Asking why they contribute

Now that we know who is contributing to Drupal, the next and more difficult question is “Why are they contributing to Drupal?” Knowing the story behind why an individual or organization contributes to Drupal will inspire more people to get involved and give something back to Drupal and Open Source.

My contribution to Drupal

This year, I was the number three individual contributor to Drupal. The previous year, when I first appeared on the top contributor list, it was completely unexpected. I joked with my son, Ben, that, "I won a race that I did not know I was running." Being included on this list was an honor that I did not expect to achieve, partially because I’m always in awe of the ongoing work by all the core maintainers and contributors.

Since last year, I have not slowed down on my commitment to the Webform module for Drupal 8. So I was not surprised to be included in this year's list. Over the past year, I have had several interesting conversations with other developers on the top contributor list, and what resonated with me the most is that everyone on this list has a different history as to why he or she contributes to Drupal. Here is more of the story.

There are different types of contributions

I found one of the biggest difference in our contributions and commitment to Drupal is whether our work is primarily sponsored or volunteer (aka unpaid).

Only 12% of the commit credits that we examined in 2017-2018 were "purely volunteer" credits (6,007 credits), in stark contrast to the 49% that were "purely sponsored". In other words, there were four times as many "purely sponsored" credits as "purely volunteer" credits.

-- https://dri.es/who-sponsors-drupal-development-2018

Right now, I would estimate < 10% of my contributions are sponsored (aka paid). The fact that I am doing all this work for free is not the norm for most contributors. It is essential to note that every single contributor that I know on the top contributor list has at one time or another contributed a ridiculous amount of volunteer contributions to Drupal before being finding an employer or organization to sponsor their work. Some people, including Dries, started contributing to Drupal in college, others do it as a hobby, and some just do it.

We all have different stories about how we discovered Drupal. Our stories begin with our first experience with Drupal, the software, which is quickly followed by our first experience with Drupal, the community. At some point, we contribute our first patch, it might take months or years for us to start contributing regularly or maintaining a project. Finally, for me and other major contributors something changed and suddenly we are spending a significant amount time contributing and helping maintain Drupal Core or a contrib project.

Why am I contributing so much to Drupal?

If I had to pick one word to describe why I contribute so much to Drupal I would have to say "Brand." I am willing to bet that most people did not expect me to summarize my contribution to Open Source with a word generally associated with marketing.

A brand is a name, term, design, symbol, or other feature that distinguishes an organization or product from its rivals in the eyes of the customer.

-- https://en.wikipedia.org/wiki/Brand 

Personal brand

The concept of a personal "brand" never really crossed my mind until I started to work with Marco Salazar, who is been my career coach for the past two years. I was inspired to work with a coach by Michael Schmid's (@Schnitzel) community keynote at DrupalCon Baltimore called "Your brain health is more important than your standing desk". Michael's first of many great suggestions was “get a coach.”

Marcos introduced me to the notion that everyone in the digital/social media world has a story and that story is communicated by one’s personal brand. The moment we create a Facebook page, a LinkedIn profile, a Twitter account, or a Drupal.org user profile, we have started to distinguish ourselves from others (aka rivals in the eyes of customers). Ironically, I never post to Facebook and rarely engage in social media, but I love to write and share code. You might say that the work that I do, the writing and sharing of code is how I’ve defined myself - my work is my way of defining myself - my content is the work. That said, all that posting, writing, creating on social media, and even coding is content

Code is content

At the heart of what I consider my personal brand is code, specifically the Webform module. Code alone is not really content.

Computer code is the set of instructions forming a computer program which is executed by a computer.

-- https://en.wikipedia.org/wiki/Computer_code

In Open Source, our shared and freely available code is still computer code but everything around the code is content. If documentation is content, presentations are also content, even a response to a question is content.

For the past three years, I have generated a lot of content around the Webform module beginning with my personal website, this blog, documentation, videos, presentations, and responding to support requests in the Webform issue queue and Drupal Answers. Ultimately all this content has succeeded in creating a name for myself in the Drupal community. Yes, being the maintainer of something like the Webform module will help get me a job interview, more importantly, content like this blog post and even how I respond to support requests help future employers and clients understand who am I and how I work.

I understand the value of people knowing about the work I do and how I do it because in the fast and changing tech industry, it is essential not to become obsolete. My favorite children’s story about overcoming the challenge of being obsolete is "Mike Mulligan and His Steam Shovel" by Virginia Lee Burton.

Mike Mulligan and His Steam Shovel

Mike Mulligan and His Steam Shovel

The story of Mike Mulligan and his steam shovel

In this story, the main character is Mike Mulligan, a steam shovel operator, and his steam shovel, Mary Anne, are being replaced by newer diesel and electric shovels because the industry and its corresponding tools are changing. The diligent and hard workers that they are, get word of an upcoming job and in an effort to not only do their job but to also prove they can do it well and efficiently, Mike and Mary Anne boast that they can dig as much in a day and 100 men can do in a week. Mike gets the job and he and Mary Anne succeed in digging the foundation for the town hall of Popperville in one day. It turns out to be their final digging job, however, the story's ending has a wonderful approach to addressing the shift in time and technology. Remarkably, the ending which was suggested to the book’s author by a 12-year-old boy is really special and should be saved for the first time you read this book to a child. I won’t totally give it away but suffice it to say, that Mike and Mary Anne are acknowledged, remembered and valued for who they are - the town of Popperville and the world shifts, but Mike and Mary Anne still have a place in society and are not lost in obscurity.

Everyone in the software industry can relate to the challenge of feeling obsolete. Even if we master the latest and greatest programming language or framework, there are dozens more that we should/could be learning. Mastering a programming language, even writing test coverage is challenging when our work is tied to deadlines and budgets. Open Source projects don't generally have budgets or deadlines; people are just sharing ideas and working to solve challenging problems.

Contributing the Webform module provided me with a new professional challenge and community

The challenge of contributing

One of my first blog posts provides a history and the process around of my work on the Webform module. That post gives a fairly complete overview of the actual work I am doing on the Webform module. In comparison, this current blog post is exploring why am I doing all the work in the first place.

Three years ago, I was reviewing my resume and felt that working with the same institution, Memorial Sloan-Kettering, for so many years (18+) was potentially going to hurt my career prospects. I noted that my work/consulting experience was very independent and contained minimal speaking and project management experience. It is worth stating that there is nothing wrong with staying a job for years, especially if they are one of the best employers in NYC

Maintaining a large Open Source project like the Webform module is more of a software architecture and community coordination challenge, then a coding challenge.

People are watching me code

In the story "Mike Mulligan and His Steam Shovel", Mike and Mary Anne get to work on what is to be their final digging job, intermittently stating that “we always work harder and faster as more people are watching us”. And there is undoubtedly something to this. It’s very rewarding when people appreciate the work I am doing on the Webform module. Watching people gradually move to Drupal 8 and start using my work is a great feeling, especially organizations and non-for-profits that I have a personal connection with, like the YMCA who include the Webform module in their OpenY distribution.

Now, that you know the story behind why I contribute to Drupal, it is also worth discussing precisely what am I contributing to Drupal.

What am I contributing to Drupal?

Every presentation and screencast I record begins with…

Hi, my name is Jacob Rockowitz

Hi, my name is Jacob Rockowitz

My sole contribution to Drupal is the Webform module. This is a very personal and deliberate decision. I am a one project kind of guy. I do my best work when I can focus on a concrete goal and purpose. Maintaining and working on a single, isolated project is not the norm for Open Source contribution. Open Source works better when people maintain some projects while contributing to others. But for me, I find I lose a lot of momentum when having to jump from one project to another. I also feel with subsystems like Webform, someone needs to be fully engaged able to add features, respond to issues and fix bugs in a timely and efficient manner.

Writing code

The Webform module is a feature-rich application. I generally add one or two new features each week and try to refactor some existing code on a bi-weekly basis. I try to break down most tasks into one to two hours of work, and almost never estimate a feature or change that will take more than four hours into a single ticket.

While working, I am very bullish when it comes to committing code - I like maintaining a certain amount of velocity as I do things. I find it really challenging to get people to review patches and frequently I will post patch, let it sit in the issue queue for a day, come back to issue, do another code review (of my code) and commit the patch.

Quality assurance

Everyone has different levels of availability and it's understandable that someone might have time to create an issue one day but not be able to come back to review the solution. I find maintaining a certain level of quality with peer review in Open Source incredibly challenging.

Drupal's core committers do an amazing job of requiring peer review and enforcing code quality. Drupal's contributed projects are a slightly different beast. Still, certain key projects like Webform need to define and continually review their process. When Webform 8.x-5.x is finally released on Christmas, I am going to review the process for maintaining a stable version of the Webform module.

For example, last year, when Webform moved into a release candidate, I started to maintain change records, which help developers and site builders get an overview on recent changes and improvements.

Knowing that my code is not always getting enough peer review and sometimes can cause regressions makes it crucial that I respond to issues and bugs.

Webform Issue Queue

Webform Issue Queue

Responding to issues and fixing bugs

Everything we post online is content, including how we respond to issues, which means our response is part of our personal and professional profile. I do my best to respond to every request almost immediately, especially if the research and resolution of an issue might only require a few minutes.

Over the past three years, I have responded to 100's of issues and support requests. Sometimes it is incredibly challenging dealing with people who take for granted that I am generally working for free. Surprisingly, sometimes my biggest feeling of accomplishment comes from being able to help someone who initially posts an issue that has "negative undertones". I always respond professionally and help them resolve their problem; they always say "thank you." I think I find hearing gratitude from someone whose initial tone was difficult or agitated to be a complete 360. And to have that kind of affect on someone feels good.

Around 50% of my commit credits are earned through quick bugs and support requests that usually take less than an hour. I also get to decide when an issue is resolved and a commit credit is earned. I agree with Dries that…

Not all code credits are the same. We currently don't have a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might receive a credit for ten minutes of work. In the future, we should consider issuing credit data in conjunction with issue priority, patch size, etc. This could help incentivize people to work on larger and more important problems and save coding standards improvements for new contributor sprints. Implementing a scoring system that ranks the complexity of an issue would also allow us to develop more accurate reports of contributed work.

-- https://dri.es/who-sponsors-drupal-development-2018

It’s really hard to determine what is and is not commit credit worthy. Even though responding to a support request does not take long, the fact that I provide ongoing and immediate support contributes significantly to people’s success with using the Webform module and Drupal.

Showing a breakdown of how a commit credit is earned, whether it be from a core or contrib task, bug fix, support request, and documentation can help us understand how everyone's commit credits are earned. And there are layers of value in constantly evaluating, learning and discovering the time, effort, energy and attitude that goes into these things.

The Drupal Association has already done an amazing job of continually improving Drupal.org user profiles, which for me is as important as my resume. The Drupal Association has also improved the tools available for creating and maintaining documentation.

Creating documentation

As the Webform module's features and user base grew, I realized that I needed to start thinking about documentation. I code better than I write but the Webform module's needs documentation. I set up the Webform module's documentation section and gradually revised different sections and pages. Before a stable release, the Webform Features page needs to be updated.

Producing help videos

I discovered the best medium for me to create documentation is screencasts. I found an amazing Creative Commons slides template and started creating and producing very simple screencasts. These screencasts are available within the Webform module and on Drupal.org. Putting a voice behind the Webform module has helped assure people that this is a supported project. Yes, these videos also help promote my 'personal brand.'

How am I able to make this level of contribution to Drupal?

The reported data shows that only 7% of the recorded contributions were made by contributors that do not identify as male, which continues to indicate a steep gender gap….The gender imbalance in Drupal is profound and underscores the need to continue fostering diversity and inclusion in our community.

-- https://dri.es/who-sponsors-drupal-development-2018

I am incredibly fortunate to have ongoing work as a consultant for a client like Memorial Sloan Kettering. This relationship gives me the ability to contribute to Drupal in between paid work. I can also write-off a lot of Open Source related expenses as professional development.

I am fortunate to have the means to contribute to Drupal.

It is important to acknowledge that gender and race play a role in how much people earn and how much (free) time they have available to contribute to Open Source. Without embarking on a much larger discussion, it’s essential to realize the gender and race inequality is more directly addressed when organizations and businesses get involved in changing things.

If more tech companies work to improve their diversity while also allowing their employees to contribute to Open Source this could tip the scales where gender and race imbalance in our community reside.

What is going to be my next contribution to Drupal?​

I am committed to maintaining the Webform Module for Drupal 8 for the foreseeable future and…

There needs to be a stable release of the Webform module.

I am willing to admit that it is time. My goal is to tag a stable release before the New Year. The Webform module has less than 50 open issues and only 4 critical issues so I think this goal is achievable.

In 2019, I would like to start exploring the next generation of Drupal Form API and Webform module. If I keep plugging away at the Webform module I can write a follow-up to this blog post in a year and maybe some of Drupal's top contributors can also share their story.

Sep 18 2018
Sep 18

Even though it is has been 20+ years since I graduated from college, every September I struggle to get back to work while also feeling inspired to learn something new.

This summer I took a rest from blogging about sustainability, but I kept on coding. I felt a little guilty thinking my blog might lose its momentum, yet somehow on the “work” side, I just kept on plugging away at the Webform module’s issues queue and managed to fix a bunch of issues and make some important accessibility and UX improvements.

Coding is what I love to do; it is what drives me.

Coding is what I love to do

As I charge forward toward a stable release of Webform 8.x-5.x by Christmas, it’s time to start thinking about what’s next for the Webform module. There are a lot of people in our community thinking and talking about the future of Drupal. Drupal and most Content Management Systems (CMS) are moving towards a decoupled and headless approach.

Headless software is software capable of working on a device without a graphical user interface. Such software receives inputs and provides output through other interfaces like network or serial port and is common on servers and embedded devices.

-- https://en.wikipedia.org/wiki/Headless_software

Beginning to think about headless Webforms and Form API (FAPI)

Webform and Drupal's Form API (FAPI) has to start supporting headless Drupal and decoupled websites and applications. The Admin UI & JavaScript Modernisation is beginning to think about and experiment with, how to make Form API work with React. React will provide us with a frontend framework to build the rich user experiences and applications that our clients and users need. Choosing a frontend framework is a big decision that necessitated a considerable discussion. React's a solid choice for a frontend framework but I’m not sure it should be the foundation for an Open Source reusable form builder.

If we could decouple form elements, validation rules, and data definitions in an abstract and reusable way, any application would be able to reuse these elements or web components.

Web components

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

-- https://www.webcomponents.org/introduction

Conceptually, I was sold on the value of web components while attending John Riviello and Chris Lorenzo’s session titled "Web Components: The Future of Web Development is Here", at Drupaldelphia. They showed how Comcast is leveraging web components across all their websites.

I also watched the "Webcomponents, Polymer and HAX: decoupling authoring for Drupal and beyond" presentation by Bryan Ollendyke and Nikki Massaro Kauffman from DrupalCon Nashville. The HAX project shows the potential of web components.

There is a lot to learn about frontend frameworks and technologies

Headless Drupal has opened up our world to a variety of frontend frameworks and technologies.

A funny thing that I have to openly admit is that I have yet to code a React application or build a single web component. It took me 20 years of no longer being a student but I can now candidly say, accept, and feel no shame admitting when I don’t really know something; while knowing I can learn it. There is no way that we can know every technology. The best we can do as good software engineers is to be comfortable with continually learning new things.

React, Web components and all frontend works are completely new to me. The heart of all frontend frameworks is JavaScript. The real challenge we are facing with moving into the headless Content Management System world is learning JavaScript.

Learn JavaScript, Deeply

Drupal has better code and API's than WordPress but I have to give Matt Mullenweg credit for directly pushing the WordPress community to become better developers. In 2015, Matt told the WordPress community "To Learn JavaScript, Deeply." The only other time I have seen a tech leader take such a direct and game-changing stand on a technology was Steve Jobs rejecting Flash in favor of HTML5. Matt Mullenweg told the developers of the most popular CMS to learn JavaScript, deeply

Dries Buytaert has shared a similar call-to-action with the Drupal community:

Sharing my journey while relearning JavaScript

JavaScript and I go back a long way. My first steps into the world of programming was using JavaScript to generate an email via an HTML form that built using MS FrontPage and worked in Internet Explorer 3. My first HTML form and JavaScript is still online and it even works after 20+ years.

My first CMS, called the Inettool, was built using JScript and ASP. The code was entirely procedural and honestly, I still have not determined the best approach to creating object-oriented JavaScript.

I will keep posting about my experience with learning JavaScript, deeply. For now, I need to wrap up development of Webform 5.x.

Wrapping up Webform 5.x and looking to 6.x and beyond

For the past 2 years, I have done an introductory presentation and screencast about the Webform module and it’s time to explore some advanced topics including testing, APIs, plugins, hooks, and more…

I will be speaking about Advanced Webforms at BadCamp in 2018. Please attend my session or like me, you might want to start learning JavaScript and attend other great sessions at these conferences and many more.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Aug 06 2018
Aug 06

It is easy to not care about accessibility, mainly because we generally don't see or understand how people with disabilities use our applications. Frankly, even usability testing can become an afterthought when it comes to building websites. There are lots of move parts to a website or an application, and it is hard to pause and ask can someone access this information using just their keyboard and/or a screen reader. The more accessible your website is, the more users you can reach and engage with your website's mission or purpose.

At Design4Drupal in Boston, caring about accessibility became the central theme for my presentation, titled ’Webform Accessibility'. After I gave my presentation, I created Issue #2979628: [meta] Improve Webform Accessibility and started fixing some obvious and not-so-obvious issues with the Webform module for Drupal 8. Andrew Macpherson, one of the Drupal Accessibility Topic maintainers, was kind enough to spend an entire train ride from NYC to Boston discussing (via Drupal Slack) form related accessibility issues and how to resolve them.

There are tools that can show you obvious problems

The most common form accessibility issue I see across the web is a failure to provide descriptive labels for form inputs. Labeling form inputs makes it possible for a screen reader to describe what input value is expected, as well as determine how it’s going to be used. For example, a screen reader needs to be able to identify a website's search box so that users can find content quickly. The solution is to provide a hidden label or title attribute to a site's search box.

Identifying what inputs are missing labels can be a difficult issue to see. Luckily, there is the WAVE (Web Accessibility Evaluation Tool) provided by webaim.org, and it shows you which inputs are missing labels.

WAVE (Web Accessibility Evaluation Tool)

WAVE (Web Accessibility Evaluation Tool)

Listening to a screen reader will tell you a lot about your forms accessibility

In my presentation I stated that "screen readers can feel overwhelming," but gradually I’ve figured out how to use them enough to understand how they work without becoming a screen reader ninja. Here’s what I’ve discovered: the simplest approach is to enable the screen reader, for OSX press ⌘+F5, and then you can use the tab, arrows, spacebar, and the enter keys to navigate focus in and out of inputs and page regions. This allows you to not only hear what information and metadata is discovered by the screen reader, but also how it is communicated to end users.

Accessibility patterns provide examples and guides to solving hard to understand issues

Javascript does not hurt a website's accessibility. Lack of awareness on how to properly use JavaScript hurts a website's accessibility.

One of the most common uses of JavaScript is to hide and show different elements and information; this behavior is called a progressive disclosure design technique.

Progressive disclosure is an interaction design technique often used in human computer interaction to help maintain the focus of a user's attention by reducing clutter, confusion, and cognitive workload.

-- https://en.wikipedia.org/wiki/Progressive_disclosure

Everyone benefits from a web page or webform with less clutter. This is why the Webform module includes support for adding help tooltips and show more slide outs to form elements. The key trick is making sure a screen reader understands how to interact with these widgets, and that these widgets are easily manipulated using navigation keys.

The WC3 provides WAI-ARIA Authoring Practices, which includes a Disclosure (Show/Hide) example and people are working on Tooltip widget example. These examples made it easy for me improve the Webform module's tooltip and show more behaviors.

Webform tooltip example

Webform tooltip example

Keyboard access can make or break an impaired user's ability to complete a form

Personally, the most important thing to respect is that not every user can manipulate a mouse - reliance on a keyboard and/or some other means to navigate a web page or form is something that needs to be of the utmost regard in creating practical and successful accessibility.

When I chatted with Mike Gifford, the other Drupal Accessibility Topic maintainer, at DrupalCon Nashville, he cited that keyboard accessibility is essential for users who might be using a sip 'n' puff to navigate the web.

Sip-and-puff (SNP)

Sip-and-puff (SNP)

Sip-and-puff or sip 'n' puff (SNP) is assistive technology used to send signals to a device using air pressure by "sipping" (inhaling) or "puffing" (exhaling) on a straw, tube or "wand." It is primarily used by people who do not have the use of their hands.

-- https://en.wikipedia.org/wiki/Sip-and-puff

The concept and image of someone using a sip 'n' puff resonated with me. The technology is straightforward while making it possible for people with major disabilities to interact with something as complex as a computer. At the most basic level, we need to respect that users need to be able to tab in and out of regions and inputs. The biggest show-stopping accessibility issue I encountered with the Webform module was the fact that once a user tabbed into the CodeMirror editor, there was no way to exit the editor using the keyboard. The WC3 recommended solution was incredibly simple: make sure pressing the 'Escape' key removes focus from the editor and moves focus to the next input. Incredibly simple and yet something that, if not fully considered, could prove incredibly frustrating.

Drupal.announce() might be the most underrated accessibility feature included in Drupal 8

Drupal.announce() provides a way to express to a screen reader changes in the state of a page, toolbar, setting tray, and any element.

-- https://www.drupal.org/node/2014521

Frankly, the Drupal community is still working on figuring out when and where changes to a page should be announced to a screen reader. The most immediate use case is telling users when something on a web page or form has changed via JavaScript and Ajax. For example, when users filter a list of modules, blocks, or form elements, it helps to tell the user how many items are displayed or if there are no results. The most relevant example in the Webform module was telling users when a multi-step webform has loaded a new page via Ajax and communicating what page a user is on. Now, when you click back or next on an Ajax-enabled multi-step webform, the screen reader will announce to the user "'Registration: Contact Information' loaded. (Page 2 or 4)."

I finally bought an Echo Dot, a voice-controlled speaker. Besides playing “Would You Rather” with my daughter, it was immediately clear to me voice-controlled interfaces are going to improve disabled people's access to information significantly. Users will no longer see our websites, pages, and forms or interact with them using a keyboard. They will be spoken to and our websites, pages, and forms need to learn how to talk back.

If you care about accessibility, make it part of your process

Accessibility is now part of my process for maintaining and improving the Webform module. The three steps that I am currently taking to check accessibility are...

  • Assess your website's accessibility using an accessibility evaluation tool

  • Listen to your website using a screen reader

  • Interact with your website using just a keyboard

I feel adding some accessibility recipes to my coding cookbook has become my extra chapter in the updated version and there is really no going back. The latest version has to include this chapter - to my mind, accessibility isn’t an option.I take pride in knowing the Webform module's user experience is inclusive and works for everyone.

I am not ready to say the Webform module is the best form building solution on the market but I will put out this bold statement/challenge…

The Webform module for Drupal 8 is the most inclusive form builder on the market.

The Webform module empowers users with disabilities and professional web developers to build powerful and flexible forms that are accessible to everyone.

For now I’ll shut up and let my keyboard do the walking and my screen reader do the talking as I build a simple contact webform from scratch.

Download the Webform module for Drupal 8

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Jun 25 2018
Jun 25

Putting together my presentation about Webform Accessibility for Design4Drupal proved to be more challenging than I anticipated. I proposed this session to force myself to begin to address accessibility in the Webform module for Drupal 8. I mistakenly thought that I could do some research and become an accessibility expert. I assumed learning about accessibility was the same as learning a new programming language - you read a book, review the docs, write some code, throw out some code, refactor other code, learn about design patterns and - voila! - you now know a new programming language. I was wrong - getting up to speed on accessibility is very challenging.

Learning about accessibility can be overwhelming

Between screen readers barking text at you and massive well-thought-out guidelines, I discovered that understanding accessibility could be overwhelming. I thought I could enable VoiceOver, the screen reader built into OSX, and start using it. Instead, I was only able to digest VoiceOver in small five minute bites, trying to reckon one of the most challenging pieces of software I have ever used. I found myself empathizing with anyone with a disability attempting to navigate a website. Frankly, many people with disabilities are likely forced to give up trying to browse websites that don't care about accessibility.

My experience with just using a tool to assist with accessibility made me want to give up.

Why do I care about accessibility?

My difficulty loomed large enough that I considered coping out and seeing if I could just do a general Webform presentation at Design4Drupal. There are three other accessibility related sessions scheduled, and I am willing to assume that these presentations are going to be more thorough and educational. But that thought nagged at me and I wasn’t so sure I wanted to relent in defeat. My hesitation made me ask myself why I was doing a presentation about accessibility in the first place, and the answer became the below slide in my presentation.

About Me & Accessibility - I know accessibility is important. I chose to ignore it for years. I now have a responsibility to address it.

About Me & Accessibility - I know accessibility is important. I chose to ignore it for years. I now have a responsibility to address it.

I realized that I had a responsibility to address accessibility and I was determined to make a presentation that explains how I can discuss this topic. This led to the next slide and rendered an unexpected central theme to my presentation.

We don't have to accessibility experts. We just need to care about accessibility.

We don't have to accessibility experts. We just need to care about accessibility.

Of course, the purpose of my presentation is to begin the ongoing process of addressing accessibility within the Webform module for Drupal 8.

Learn more about accessibility

If you can make it to Design4Drupal, please attend my presentation and/or the three other presentations about accessibility.

If you can't make it to my presentation, you are in luck because one of the things I do to prepare and practice my presentation is record it. You can watch my rehearsal presentation and review my slides below. If nothing else, it’ll show that while I am no expert, I do care.

View and Download Slides

Get involved with accessibility

The most important thing that I want people to take away from my presentation is that they need to care about accessibility. You don't need to be expert to get involved.

Here are some places to start learning about accessibility and getting involved.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

Jun 11 2018
Jun 11

These are some of the ingredients that can make open source sustainable

The title of this blog post, "Project Management + Estimation + Mentorship = Sustainability" does not represent an exact formula for solving the challenges of open source sustainability. It establishes what I feel are the ingredients to a recipe that could significantly improve the sustainability of open source projects. To discover the right recipe for sustainability, it is key to define sustainability.

Defining open source sustainability

Open source sustainability is the ability of a community of people and organizations to collaboratively contribute to software that is freely available for anyone to use and alter.

The above description could sound like a standard cooperative or partnership agreement except that the General Public License (GPL), attached to most open source projects, makes the product of this arrangement entirely free for anyone to use and alter. This is the challenge of open source sustainability: the result of our labor, aka the product, is absolutely free. There is no doubt that people and organizations have found incredible value in open source software. But what is the value of the labor?

If no one owns something that is so important to us, how do we know that it will be cared for?

Personally, I am passionate about maintaining my project the Webform module for Drupal 8, because it is my baby. The reality is that our kids grow up and we need to make sure they are independent and healthy. We put in the time and effort because we consider it worthwhile and because we care. This parent/child analogy helps clarify the simple but key notion that everyone who contributes and is involved in open source cares about their project and community. People and organizations contribute a considerable amount of time to build and maintain their open source projects. It’s time and energy that could equate to money.

Time = Value = Money

Let's accept the reality that when a developer contributes to open source, they are typically taking time away for their paying jobs (and family) to write code, respond to issues, and even mentor contributors. Open source has added a massive amount of value to our work and society. Open source software is everywhere. It is on our devices and is used and relied upon by every tech giant.

Open source software requires time that results in high quality and valuable software, which has monetary value.

Money != Sustainability
(Money does NOT equal Sustainability)

When I was first starting thinking about how I could make my massive contribution to Drupal sustainable, I mistakenly thought money would automatically solve my problem. Money helps, but when money enters an open source collaboration things get more challenging to manage. One of the big takeaways from the Request for Commit podcast is that even when an open source project has funds, it’s complicated to determine how to distribute this money.

To properly propose, collect, track, distribute, and manage the funding of open source projects there needs to be a process.

Process = Sustainability

We are a community of people contributing to a vast collaboration, and this collaboration is defined and driven by our process. The fact that Wikipedia’s definition of 'Software maintainer' originates from Open Source software says so much about our process.

In free and Open Source software, a software maintainer or package maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in a source repository.

-- https://en.wikipedia.org/wiki/Software_maintainer

The role of software maintainer does not exist unless people contribute patches to be committed to the project. Software maintainers are mentoring contributors when they are reviewing patches. We are all mentoring each other when we review someone else's patch.

Everyone needs a mentor, and everyone is a mentor in open source.

Mentorship is what grows open source

Mentorship is a relationship in which a more experienced or more knowledgeable person helps to guide a less experienced or less knowledgeable person.

-- https://en.wikipedia.org/wiki/Mentorship

Mentorship helps to encourage high-quality contributions while also growing the community around open source software. It is essential that we embrace this very basic aspect of opening source development. Mentorship and code review is something that everyone understands and values.

Code review ensures quality and security. Organizations generally trust open source software because they know that multiple people review patches and pull requests before they are committed, and everyone is continually reviewing the code after it has been committed.

Open source communities need to leverage the fact that all code is peer-reviewed before and after it is committed to a project, especially when approaching organizations to fund and contribute to open source projects.

Getting organizations involved in funding and contributing to open source is crucial to improving sustainability.

Organizations need to be involved and committed to open source sustainability

Initially, I thought that leveraging the importance of mentorship and peer code review would inspire everyone to help fund and sustain open source. My mistake in this approach is that it is only applicable to people and organizations who understand and are involved in open source - they already care about and value mentorship and code review. The real challenge for improving open source sustainability is getting people who are not involved, yet rely on open source, to start contributing and funding the open source projects on which they depend

The more we can inspire people and organizations to become involved in open source the more sustainable we will make our projects and community.

How do we get people and organizations more involved in open source?

I found that the only way to begin answering this question is to step into the shoes of people and organizations who are not part of open source. One of my most immediate conclusions was…

People and organizations need tangible results to justify contributing to open source.

It is entirely fair for anyone being asked to contribute to open source to question what do they get in return. Sorry, but "free software" is too vague of an answer and there are some fantastic articles and blog posts that do provide great arguments as to why people should contribute to open source. Generally, we tout the benefits of contributing to open source and every project, including Drupal, offers ways to get involved. Open source development is a different process than what anyone is accustomed to in their regular day-to-day education or employment. Open source projects tend to not have tightly structured organization charts, hard deadlines, salaries or holiday bonuses. There are certain aspects of how businesses work that undeniably make sense and help everyone get their jobs done in a productive and happy work environment.

People and organizations need a tangible process to contribute to open source.

Yes, open source is a different process which changes from project to project. Two things I found that were typically under-recognized in most open source projects is the importance of project management and estimation.

We are underestimating the value of estimation

Estimation helps set reasonable expectations

Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.

-- https://en.wikipedia.org/wiki/Estimation

My last blog addressed, "Are we afraid to estimate our work in Drupal and Open Source?" and I hope the biggest take away is that estimation helps set reasonable expectations that make it easier for people and organizations to get involved in open source. Improving estimation within our open source projects would remove the "incomplete, uncertain, or unstable" aspects from our work. Estimation, even incorrect estimation (there will undoubtedly be trial-and-error periods), allows everyone to better understand the amount of work that needs to be done and the money required to accomplish it.

Discovering and improving how we collaborative estimate within open source would make everyone's experience more enjoyable and productive. I want to emphasize that anyone who gets involved in open source should have an enjoyable and productive experience

Excellent and thoughtful project management is what ensures that everyone is productive and happy.

Project management helps people be more productive and happy

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time.

-- https://en.wikipedia.org/wiki/Project_management

Open source software is created via a massive team effort from people spread out across the globe. We have created a process where people collaborate to develop high quality, valuable, and secure products. Along our journeys to develop open source software we have built amazing communities that consists of more than just developers, and include people from every role in the software industry. Generally, open source does attract more developers because they write the code.

I am one of those open source software developers. I value my experience within open source but I have also come to understand that open source software is more than writing code - it is about the process of contributing code to a community.

The open source process has some major problems. Personally, at the beginning of this year, I recognized the risk of burning out and recently wrote about offboarding contributors. My post concluded with the realization that improving how we manage our projects and how the role of project management is going to keep open source communities healthy and sustainable.

Besides keeping people within the open source community prosperous, better project management will make it easier for people and organizations outside of open source to become members of our community.

Estimation combined with project management makes it easier for people and organizations to contribute to open source

Let’s acknowledge that Drupal is being used to build enterprise applications for some very big organizations. Some of these organizations have the potential to bring their game-changing resources to our community. Fortune 500 companies can easily contribute a few hundred thousand dollars to Drupal and open source. And some do because they see it as an investment. Frankly, I think the only thing limiting more organizations from investing in Drupal is the fact that it is hard for them to understand precisely what they will be getting for their money. Estimation would help them in that regard.

I am willing to go a step further and say that…

Better project management will increase the level open source contribution from existing contributors.

1 Project Manager = 100 contributors

Open source projects are always looking for new contributors. Open source disproved the notion that adding more developers to a project does not increase productivity. Still, open source needs to pay attention to everyone’s experience when contributing to open source. Thoughtful and excellent project management can make the difference between a developer making one contribution vs. a developer making a sustained ongoing contribution to an open source project.

I have personally seen numerous times how a good project manager can mediate conflicts and negotiate resolutions with our community. Project managers make sure developers don’t burn out while making sure a stakeholder's needs are addressed.

Project managers can help ensure that people and organizations get tangible results when they contribute and support open source.

Showing the value of project management (and leadership) in open source

Gábor Hojtsy, the multilingual initiative lead for Drupal 8, learned and shared his incredible experience, scaling Open Source projects, how 1300+ improved Drupal 8’s multilingual features. His leadership shows how careful project management can get people involved and providing sustainable contributions to an open source project.

Addressing the challenges of mentorship, estimation, and project management

To improve sustainability within open source we need to address a few challenges.

First, we need to explore how to make sure people and organizations get the most out of their experience when contributing and funding open source. Encouraging mentorship fosters a healthy interaction between software maintainers and contributors. Estimation sets reasonable expectations for people and organizations working within open source.

Secondly, I strongly feel that improving and valuing project management is the unrecognized secret sauce to growing open source communities and ensuring that people and organizations have a positive and sustainable experience.

Finally, open source communities must respect that some organizations need to see tangible results when contributing and funding open source software.

Recipes require taste testers.

This recipe, 'Project Management + Estimation + Mentorship = Sustainability' is going to require some more thought, experimentation, and tweaking. This summer I am going to do a more in-depth exploration of the recipe and open source sustainability.

For now, I would love to get your first impressions and thoughts in the comments below.

If we consider all the projects we’ve successfully collaborated on thus far, it’s a no-brainer that we can come up with some pretty great solutions when it comes to estimation too.

By this Fall, I am hoping we can try out some new sustainability experiments

May 30 2018
May 30

Estimation is not a new concept nor is it a bad word.

Estimation is not a new topic for anyone in the Drupal or open source community. We do it every day at our jobs. We even discuss estimation techniques at our conferences. We provide our clients with estimates when building and contributing back to open source project, yet we don't include estimations within our open source community and issue queues.

We all provide estimates to our clients - are we afraid to do it when it comes to Drupal and Open Source?

Before we take on this tough question, 'Are we afraid to estimate our work in Drupal and open source?', let's start off with a straightforward question: 'Why do we provide estimates to our clients?' The answer is just that our clients want to know how much something is going to cost and we want to know how much work is required to complete a project.

To give this discussion more context, let's begin with a very general definition of estimation

Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.

-- https://en.wikipedia.org/wiki/Estimation 

Here’s my hypothesis:

The lack of estimation in open source is hurting the onboarding of new contributors and the ongoing sustainability of our projects.

The Science of guessing - Drupal estimation techniques from project managers

While researching estimation within the Drupal community, I found a bunch of great presentations about project management and estimation. To me, "The Science of guessing - Drupal estimation techniques from project managers" by Shannon Vettes (svettes), Jakob Persson (solipsist), and Mattias Axelsson (acke), was the most comprehensive and inspiring presentation. Feel free to watch this presentation. I am going to pull a few slides from this presentation to help move through this exploration.

Every presentation I watched focused on estimation concerning managing expectations for client/employer based projects. Yet, no one addressed estimation within our open source projects.

Open source projects are afraid to estimate because everyone is working for free

I know the above statement is a broad generalization but until only a few years ago one of most popular credos in the Drupal community came about when it came to the release of next version Drupal. It was/is…

It will be ready when it is ready.

I am glad to say this policy is no longer applicable to Drupal core because the community has committed to regular six month releases. Still, I feel we struggle to commit to specific deadlines. Yes, we have rough timelines for when core strategic initiatives might be completed, but the truth is these timelines are guesstimates because as a community we don't include any estimations within our issues queue or process. We don't have any accurate metrics tracking productivity, velocity or return on investment.

For example, a few years ago our community came together to create the Drupal 8 Accelerate Fund and it is worth asking some general questions about that collaboration.

Was the Drupal 8 Accelerate Fund successful? What was the return on investment? How much work was completed for 2,500 man hours at $100 per hour?

A general question for the Open Source community is...

If an open source project began to collaboratively and publically estimate tasks, would we be able to give accurate timelines and roadmaps?

Maybe we don’t know where to begin but we have to begin somewhere. To get answers, we have to ask the questions.

I want to emphasize that I am criticizing our process and not any individual, team, or organization. I am asking a tough question because I want us to solve the problem of sustainability. Building and sustaining an open source project has a cost and we need to know what that cost is.

How has not providing estimates impacted our open source projects?

Personally, I have seen how the lack of estimation has impacted the Webform module's issue queue. I have seen incredibly challenging tickets that lacked a clear estimate of the amount of work to be taken on by someone, only to see them become frustrated because they are unable to complete the task. I have patches in the issue queue for tasks that are so complex I don't have time to review the code. My failure to estimate specific tickets has led to another common problem that estimation helps to address, which is breaking down complex tasks into smaller more manageable steps.

If the Drupal community wants to get big and small businesses involved, we need to be able to provide realistic estimates. We need to have real and practical examples - to be able to say based on our community's history and these statistics, if you give X dollars, we can complete this initiative or task which will help benefit your business.

We don't need to be afraid to ask people to estimate as long as we all acknowledge that everyone's level of commitment is going to be different. Open Source projects generally employ no one. We would need to collectively discover the best estimation technique while factoring in a realistic level of commitment that a developer or business can make to completing an open source task. And yes, we also need to track how funding impacts an open source project.

How would estimation benefit open source projects?

The below chart from 'The Science of Guessing - Drupal estimation techniques from project managers' shows how estimating the value, effort, and risk helps everyone understand what work needs to be done and what probably does not need to be done

Estimation: Why do we need them?

Estimation: Why do we need them?

For me, the sweet spot, low-hanging fruit are easy to complete tasks, and an essential quadrant for onboarding new contributors and keeping existing contributors engaged, especially if they only have a few minutes available to contribute. Personally, I always start out my work week going after a few easy tasks before taking on the more challenging tickets which bring a lot of value to the Webform module.

Some great examples of low-hanging fruit are documentation, patch reviews, minor user interface tweaks, reviewing and improving test coverage. Realistically we need to break down complex tasks into simpler easier to complete tasks and user stories.

Having estimation in our open source issue queues will make it easier for people, organizations, and companies to get involved.

Businesses and organizations need to know how to plan, budget, and communicate what it costs to contribute to open source

Estimates help us: Plan, budget, and communicate

Estimates help us: Plan, budget, and communicate

I persuaded my main client Memorial Sloan Kettering to become one of the largest earliest adopters of Drupal 8. The Memorial Sloan Kettering website was built while Drupal 8 was still in alpha releases and launched on a beta release. Memorial Sloan Kettering did contribute code back to the Drupal community but it was difficult to plan and budget for funding any module upgrades from D7 or D8 because project maintainers tend not estimate how much is required to upgrade a module. We worked with guesstimates and managed to upgrade a few modules.

Imagine if we were able to provide reasonable estimates, based on historical information combined with a collaborative methodology, to organizations. Imagine being able to say to company A if you allocate X dollars to this specific open source initiative, project, or task, we can accomplish B features.

So let me put my dream into a real-world context; every organization in the EU needs to comply with the General Data Protection Regulation (GDPR) and make sure that they are protecting their users' data while making this data available and portable to each user, and ultimately deletable. This is a very broad generalization of the GDPR but to comply with these regulations, there are going to have to be several improvements made to the Webform module. These types of features could be broken down into individual tickets with collaborative estimates so that organizations can allocate resources and/or funds to help themselves and their community comply with the GDPR. BTW, Drupal core is facing the same exact challenges with GDPR.

How could we collaboratively estimate in our open source projects?

There are many different techniques for estimating. The only concrete requirement that I feel is a must is that we use collaborative estimation technique.

3 Example Techniques: Ball Park Top-Down, Weighted Estimate, and Delphi Methods

3 Example Techniques: Ball Park Top-Down, Weighted Estimate, and Delphi Methods

Personally, I like the concept of planning poker which is a form of the delphi method.

Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development.

-- https://en.wikipedia.org/wiki/Planning_poker

I also like using story points to scope out the overall level of effort required for a ticket.

A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

-- http://www.tothenew.com/blog/how-to-estimate-story-points-in-agile/

Even being able to categorize and label tickets as easy, medium, and hard could make a big difference. Currently, in our issue queues on Drupal.org we can apply these types of tags to tickets, but users have to use the advanced search to filter by any tag. It’s not reasonable to expect a new contributor looking for an easy ticket to use an advanced search.

We also need to collaboratively calculate the value of our tickets

So imagine if you have been using Drupal for a few years and finally wanted to contribute something back to the community, and started looking for something to do. You find a task that several people have marked as easy to do and also provides a lot of value. Even if you have questions or run into a problem with the task, you might find a mentor in one of the people who helped estimate that ticket.

What challenges should we begin to collaboratively estimate?

Every GDPR task is going to provide a lot of value to organizations in the EU. Personally, I feel it is also important that we start recognizing the inherent and ongoing value in improving accessibility in our software.

Frankly, there are probably feature requests in the Webform issue queue that I do not see the value in and people are not able to collaboratively communicate the need and importance for these features. For instance, I am not actively doing any headless Drupal work; I am not sure of the value of improving the Webform module's REST API's. I guess that specific organizations see a lot of value in using the Webform UI/UX to build form's which can be served via a REST or JSON API.

What is my key point?

We need to stop guessing the value and work required to complete a task. We should collaboratively determine the value of a task and estimate the amount of work necessary to complete the task. Understanding the value, effort and cost required to get things done will make it easier and more rewarding for individuals and organizations to get involved and stay involved in open source communities.

How can we make estimation happen in our communities

What affects estimation? The Usual Suspects

What affects estimation? The Usual Suspects

I knew I had to include the above slide for the presentation in this post because it portrays the challenge of getting people, especially developers to provide reasonable estimations. Developers tend to suck at estimating which is why the role the project manager exists. Project managers are the keepers of the process. My last blog titled 'Our journeys within our community,' I concluded with the realization that project managers are one of the key roles in our open source community. When it comes to addressing the challenge of estimation within our open source project they are the best qualified to help define and discover the best technique to estimate our work collaboratively

Good estimation happens when there is a good discussion followed by some agreement and action.


Since this blog post began with the hypothesis that, "the lack of estimation in open source is hurting the onboarding new contributors and ongoing sustainability of our project", it must end with a conclusion.

It's hard to conclude how the lack of estimation is hurting our projects because we don't have a concrete metrics to work with, except the fact that everyone is relying on and contributing to open source.

To improve open source sustainability we need to examine our process and how we collaborate to create open source software. Estimation is a key part of the process of building software.

We need to determine the best recipe to sustain and grow open source. My most recent blog posts have circled around the problem and challenges of sustainability. I feel the below formula/recipe could help us solve the problem of sustainability.

Project Management + Estimation + Mentorship = Sustainability

Examining this formula will be the topic for my next blog post.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly

May 16 2018
May 16

To begin to address sustainability in Drupal and Open Source, it’s important to explore our journeys within the community. We need to examine how we work together to grow and build our software and community.

This is going to be one of the most challenging blog posts I have ever written because I am uncomfortable with the words: roles, maintainers, contributor and mentoring. All of these words help establish our Open Source projects and communities. Over the past two years, while working on the Webform module I have learned the value of how each of these aspects relates to one another and to our Open Source collaboration and community.

Why am I uncomfortable with these words?

I am uncomfortable with these words because my general mindset and work habit are very independent and individualistic, but living on this island does not work well when it comes to Open Source. And changing my mindset and habits are things that I know need to happen.

Like many programmers, I went to art school where I learned the importance of exploring and discovering one's individual creative process. Another thing I had in common with many people who went to art school - I needed to figure out how to make a living. I went to the Brooklyn Public Library and started surfing this new thing called the World Wide Web. I was curious, confident and intrigued enough to realize that this was something I could and wanted to do - I could get a job building websites.

I built my first website, http://jakesbodega.com, using MS FrontPage while reading the HTML Bible and tinkering on a computer in the basement of my folks’ big blue house. After six months of self-teaching, I got my first job coding HTML at a small company specializing in Broadway websites. Interestingly, with the boom of the Internet, everyone's roles were constantly changing as companies grew to accommodate more and more organizations coming online.

My first experience with the notion of a Content Management System (CMS) was completely breaking a website by deleting a single server-side include. Sadly, what followed was the technology lead not seeing my mistake as an opportunity to teach and mentor me, but to ridicule me for not understanding that a server-side include is just a directive to pull the content of another file into the current file. BTW, I take pride in being a member of a community where the notion of ridicule is never accepted - there’s truly nothing to be gained from it. Rather, the worst response one might get is a link to https://en.wikipedia.org/wiki/Server_Side_Includes.

This negative experience made me buckle down, buy more books, and take the mindset that I’d just figure it out, which I did. I literally built a custom CMS, called the Inettool, from scratch using ASP/JScript. When I recall that experience, I still wish that I’d had a better role model who understood their responsibility and role as a technical lead and mentor.

Discovering Open Source and Drupal changed my mindset. Besides not having to maintain a custom CMS, I am still in awe of the roles and responsibilities that people take on in the Drupal community.

Understanding the roles in open source

My son Ben, who you met in a recent blog post, and I recently listened to Command Line Heroes: OS Wars_part 1. Besides comparing Linus Torvalds to Luke Skywalker, which immediately hooks any twelve-year-old, the host, Saron Yitbarek, does a great job explaining how everyone thought the Open Source experiment, Linux, would fail. How could developers come together to build a free Operating System? Looking back now, the answer is that somehow developers took on different responsibilities and worked together to define new roles, including the concept of software maintainership and contribution.

The importance of the software maintainer

In free and Open Source software, a software maintainer or package maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in a source repository.

-- https://en.wikipedia.org/wiki/Software_maintainer

Wikipedia's description of a software maintainer is very intriguing because the role of a maintainer is being explicitly defined for Open Source software, however the rest of the description is very technical with no mention of mentoring or fostering a community around Open Source software.

In the Drupal community, we all understand and appreciate the value of core and contrib project maintainers. I think it’s pretty evident that I take the role and responsibility of being the maintainer of the Webform module very seriously. And though I receive a lot of appreciation, the reality is that the role of being a project maintainer can be exhausting. The role of maintaining a project is not just about writing code. I’ve probably earned most of my commit credits by just responding to general support questions and welcoming people in the Webform issue queue.

I really enjoyed Jeff Geerling’s (geerlingguy) presentation Just Keep Swimming: Don't drown in your open source project! because it explores, "the problems maintainers deal with on a daily basis, and equips you with tools to reduce the number of problems in the first place!"

I particularly appreciated Geerling’s dissection of the different types of contributors. I am continually discovering new types of contributors, and I never cease to be amazed how someone can glance at something as complex as the Webform module and solve bugs that have dumbfounded me for months.

Everyone is a contributor

Conceptually, everyone in Open Source is a contributor, they just operate at different levels. As a project maintainer, I am contributing to Drupal's module ecosystem. Someone speaking at an event about Drupal is contributing to the general awareness and education of people in our community.

If an Open Source project does not have contributors, it’s just code that is freely available. The notion that everyone is able to contribute is the force that binds our community together. We should never forget that contributors may one day become maintainers.

Mentorship is what grows our community

So I have to confess: I have never attended a code sprint. And my comfort zone of working independently means I am very uncomfortable with the notion of sitting in a room with other people writing code. For lack of a better phrase, I get "code sprint fright."

Code Sprints - DrupalCon Boston

Code Sprints - DrupalCon Boston

Drupal Sprints - DrupalCon Baltimore 2017 - Michael Cannon

I now see the importance of code sprints. They bring our community together and strengthen our collaboration. If I really want the Webform module to grow, there is a limit to how much code I can write and maintain, however, there is an unlimited number of people available to help me write and maintain this code. If I ever want to step away from maintaining the Webform module in a responsible way, I need to mentor contributors who can take over the reins. I need to conquer my "code sprint fright."

When Leslie Glynn (leslieg), who is organizing the Design4Drupal (June 27 - 29), asked me if was going to attend the code sprints, I explained my fear of coding in public and she pointed out that I don't have to code at a sprint; rather, I can share ideas and help people solve their coding problems. It seemed like a great suggestion to ease me in. She made me optimistic that I can overcome this major personal hurdle.

I know mentorship and collaboration is the key to Open Source's success and it’s the most important thing we need to protect while working to make Open Source sustainable. The most important and underacknowledged role that makes Open Source happen is the project manager.

The most important and underacknowledged role: the project manager

Like most developers, I’m guilty of only seeing and discussing our process and community through the lens of someone who writes code. After this examination of roles, maintainers, contributors, mentoring, and process, I’ve realized that I have ignored what might be the most important and under acknowledged role in our community: the project manager.

When I look back at the problems and challenges I have discussed including on-boarding, contributing, and off-boarding, the role that is going to have the biggest impact is the project manager. It’s the project manager who can coordinate everyone’s efforts while also ensuring that everyone is successful and happy. It is important to acknowledge that project management is a distinct and important role, which most maintainers do while also reviewing patches and wrangling an issue queue.

Final thoughts

I knew when I began writing this blog post that mentorship is key to improving Open Source sustainability. I did not expect to conclude that the role of project manager is what makes everyone's journey in Open Source possible, healthy and sustainable.

We need to reevaluate the simple notion that adding more developers to an Open Source project will improve its productivity and sustainability. At the same time, we need to realize that the role of a project manager is what coordinates and defines the process that builds successful and sustainable Open Source projects and communities.

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web