Feeds

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!

OK

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.

Collaboration

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?

Businesses

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.

Call-to-action

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!

OK

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.

Accomplishing

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.

Deprecating

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.

Smelling

"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.

Understanding

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!

OK

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.

Strategies

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.

Completion
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.

Events

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.

A/B

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.

User

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.

Recommendations

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.

Navigation

Easy

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.
 

Directions

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.

Information

Expectations

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?

Grouping

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

Explanations

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

Relevance

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.

Experience

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

Conditionals

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.

Indicator

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.

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

Accessibility
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

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

JavaScript

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.

Indicators

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

Browser

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.

Information

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.

Labels

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

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.

Phone

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."

Confirmation

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.

Buttons

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.

Layout

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.

Theming

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.

Results

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.

Widgets

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!

OK

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.

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

Evaluation

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!

OK

Aug 19 2019
Aug 19

Experience

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

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!

OK

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!

OK

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.

Guidelines

  • 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

Goals

  • 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.

Guidelines

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

Goals

Open to

Guidelines

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!

OK

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

Communication

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.

Documentation

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!

OK

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!

OK

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.

Tee-shirts

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…

REGISTER TODAY

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

Problem

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?

Solution

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).

Notes

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.

Demo

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?

Persuading

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.

Continuing

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?

Webform

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
https://techcrunch.com/2018/06/23/open-source-sustainability

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
https://www.drupal.org/project/simpletest/issues/176124

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
https://www.drupal.org/project/office_hours/issues/2450191

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.

IMCE

IMCE

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

ufku

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.

Conclusion

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

May 07 2018
May 07

People come and go from open source projects and communities

Most people would agree that everyone should contribute something back to Open Source at some point in their careers. We have to realize that an ongoing Open Source contribution to a project can't be sustained forever. We might graduate from college, get a new job, need a break to travel, have kids, help raise grandkids, retire and even get bored with a project. While we need to improve open source sustainability, we also need to accept the reality that people continually come and go from open source projects.

Developer burnout should not be part of open source

Up until recently, I felt that 'burnout' was the only talked about method when people left the Drupal community. Up until DrupalCon, I thought that once I committed to supporting something, like a module, I was obligated indefinitely or at least until I burned-out from supporting it.

In my new year blog post title, Webform, Drupal, and Open Source...Where are we going?, I stated…

I am destined to burnout

...and I don't think I am the only one.

Are we expecting too much?

Jeff Eaton's presentation titled "You Matter More Than The Cause" addresses burnout and how it impacts the sustainability of teams and he says…

"Everyone was expected to give a 110% and one-hundred and ten percent is not a real number."

I think we need to stomp out the concept of developer burnout in Open Source and equate developer burnout to poorly-managed companies and organizations.

Planning an exit strategy can prevent burnout

One of many valuable lessons I learned at Adam Goodman's Teamwork and Leadership Workshop at DrupalCon Nashville was that it’s okay to plan an exit strategy, it’s even something that can ultimately help the community and potentially prevent burnout.

"Planning an exit strategy" means defining specific limitations around your responsibilities and commitments to complete a task. This helps everyone plan for the succession of duties. Adam's personal example was that before he took on the role of being the Chair of the Drupal Association Board of Directors he wanted the commitment to be for a defined amount time.

Personally, I have decided that every task that I do in the Drupal community should include an exit strategy before I commit. When offering to help get an 'About Drupal' content section in core, I have committed myself to getting the initial content and section built while needing to get more people involved to help iterate and improve the content moving forward.

Growing our tribes can create sustainable and healthy micro-communities

For Open Source communities to be a healthy ecosystem, we need to acknowledge the life cycle of our projects and people. New people join our community every day while other people regularly leave our community for new challenges. Since our community and ecosystem is built on people's commitment and passion, we need to think about how we grow and sustain our 'tribal' community.

Shannon Vettes’ presentation titled "Growing Our Tribes: Creating Sustainable Micro-Communities in Drupal and how you can help" about DrupalCon Nashville succeeds in defining a tangible approach to improving how our community works together and collaborates. Shannon is applying the concepts behind tribal communities to build more sustainable 'micro-communities' in Drupal and open source. Simply put, Drupal is huge and daunting to everyone involved. No one can understand or contribute to every aspect of Drupal, which is why we need to recognize that different aspects of Drupal like committees, project initiatives, contributed modules & themes can be thought of as micro-communities and tribes.

Shannon's project management perspective is essential to helping us solve the sustainability problems around open source software. I have concluded that technology alone is not going to solve the challenge of ongoing sustainability for open source projects. I feel that content and process is what will make open source projects more sustainable. I have begun to talk about Content First, Technology Second, seeking to add some messaging about the Drupal community into Drupal the software's user experience. For me, Shannon's presentation gets to the heart of what defines a successful open source community, the connections between people and how they collectively work together.

I love that she emphasizes the need to acknowledge what I want to call the three phases of contributing to open source.

  • Onboarding: The process of getting involved.

  • Contributing: The process of productively contributing.

  • Off-boarding: The process of winding down one's involvement.

I feel as a community we have always thought about how people contribute and we are re-addressing onboarding process by improving our evaluator experience, but we are not fully addressing the off-boarding process. And we need to because how we off-board people can have a positive or negative impact on the overall health of our community.

Each one of these phases requires a dedicated blog post, DrupalCon presentation, and maybe even a dedicated core initiative and team. For now, I want to talk about how we say goodbye.

What are we communicating about offboarding on Drupal.org?

Finding new maintainer or co-maintainer for your project and dealing with unsupported (abandoned) projects are the only pages that I am aware of that begin to address what happens when people leave the community.

I am not sure we need a "How to abandon a project" page on Drupal.org but maybe we need to look at documenting the open source contributors journey from beginning to end and make this part of the user experience on Drupal.org and maybe even in Drupal's (the software) user experience.

Documenting the open source contributors journey

Chris Albrecht's presentation title "Managing Your Most Important Resource: You" from DrupalCon Nashville explores Albrecht’s journeys within the Drupal community. He tells his very personal story about getting involved in the Drupal community, experiencing burnout, attending DrupalCons, maintaining a module and even not maintaining a module. He concludes with offering really sound advice on how to adjust one's priorities when working in open source and life.

Before we ask someone to get involved in Drupal, we should talk to them about the overall journey into Drupal and open source software. This journey should be about being human, being part of our community, and highlight members of our tribes & micro-communities - not about fixing bugs and reviewing patches in an issue queue.

Along the way we should tell people..

It is okay to plan an exit strategy, we are here to help and listen if you need break, and it is fine to say goodbye.

Conclusion

There is some irony that my last two blogs posts were about saying "Hi" in Drupal (the software) and at my local Drupal NYC meetup and now this blog post is about saying "Goodbye". Saying hi and bye is about communication and if it is done right, with some empathy, we can strengthen and grow our tribes. Goodbyes should be built into the equation, viewed as something that could potentially have to or need to happen along the way, and not something someone does - or doesn’t do - as a result of burnout.

Almost done…

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

OKSubscriptions powered by Strikingly

Apr 30 2018
Apr 30

The importance of welcoming people to the Drupal community

Our meetups and in-person interactions are where we welcome and include new people in our community. Of course, people come and go from every community; new faces bring new ideas and innovations.

Everyone has a story about the first person they met in the Drupal community.

At the beginning of DrupalCon Nashville at the Community Summit, someone told a story of how they attended a meetup and literally no one talked to them or even really acknowledged their presence. As a result, the individual never returned to that meetup. Organizers of meetups absolutely need to make a concerted effort to make sure that everyone who attends is - minimally - welcomed and acknowledged - that is community-building 101. This story really sat with me because it made me question whether I’m doing enough at the local NYC Drupal Meetup to make people feel welcomed and included.

Remembering who welcomed me to the Drupal community

I ran into Robbie Holmes (robbiethegeek) at DrupalCon and standing in exhibition hall, we reminisced about how he was the first person who welcomed me to the Drupal community. An interesting fact about our relationship is that we grew up around the corner from each other in Brooklyn and knew the same people, but met for the first time in the Drupal community. For many years, Robbie, with the help of others in the community, would always offer to split off from the general, sometimes very technical discussion, to offer a newbie discussion where people new to Drupal can ask them anything and get help. To date, Alexander Ross (bleen) was initiating these discussions at the NYC Drupal Meetup, but it is not reasonable to expect one person to be responsible for welcoming people to the Drupal community.

We all need to start welcoming people to our community.

So, I am going to commit to helping ensure that our "Welcome to Drupal” discussion happens at every local NYC Drupal meetup and make sure that I am not doing it alone. Luckily, I have plenty of friends in the NYC Drupal community who would be okay missing one or two discussions to help me welcome people to our community.

What are three immediate things I can do at the NYC Drupal meetup to welcome people

As many people know, I have included the Contribute module's message into the Webform module and even have a few slides about "How can you contribute to the Webform module & Drupal?" in my DrupalCon Presentation titled "Webform: There is this for that". After my experience at the Community Summit and several great conversations with people at the conference, I decided to step back from the Contribute module's message and think about what is the most important thing that needs to be said to people new to Drupal. At 5 AM, the day of my presentation, I decided to include the below animated slide, which starts off with saying "Hi". BTW, please read my last blog to understand why I feel saying "Hi' is important.

Hi! Welcome to our diverse & inclusive community! How can we help you? Here is how you can get involved.

Hi! Welcome to our diverse & inclusive community! How can we help you? Here is how you can get involved.

Welcome to our diverse & inclusive community!

In addition to saying the oh-so-important “hi”, including the words, diverse and inclusive, when we welcome people and in our software's user experience could have a profound impact. It will definitely distinguish us from other communities. The reality is that these are just two extra words being added to our greeting, and we need to follow-up these words with real actions and meaning. We need to take it one step further.

How can we help you?

Saying "How can we help you?" is the easiest most direct way to break the ice and make someone feel comfortable and welcomed. It’s akin to saying, “hey, you matter and you have value.” Robbie and Alex are role models for the best approach to welcome people to a meetup, which is to say that we are hear to listen to the problems and challenges that you face and want to help you find solutions.

Here is how you can get involved

The 'Getting Involved' section on Drupal.org does a great job of welcoming people and directing them to all the different ways to get contribute.

As an open source project, we don’t have employees to provide Drupal improvements and support. We depend on our diverse community of passionate volunteers to move the project forward by working on not just web development and user support, but also many other contributions and interests (such as marketing, organizing user groups and camps, speaking at events, maintaining documentation and helping to review issues).

At Drupal meetups, I think there is specific opportunity to grow our communities diversity of speakers and presenters at local meetups, and even at DrupalCon by encouraging and helping people put together a presentation and practice public speaking. I really enjoy seeing people presenting what they are working on and/or what they love about Drupal. I personally remember that nervous shaky feeling of getting up in front of a group of people and giving my first case study presentation about Memorial Sloan Kettering Cancer Center. At the same time, I have seen the professional value of public speaking, and how valuable it is to have this noted on my resume and personal website. Including a bullet point on your resume that says you presented at local Drupal Meetup says so much to a potential employer, starting immediately with the fact that you are more than just a coder and you participate in the software community. The ability to communicate with others is key to growing and developing any community. Drupal is not an exception to this fundamental rule - no organization is. And it can only enhance what we have created to date.

Closing thoughts

Open Source has proven it can redefine how software is built and it has resulted in redefining how online communities collaborate. Now it’s time to make certain that everyone is invited, able, and comfortable enough to join our communities and even make them comfortable standing up and presenting in front of their fellow developers and get involved in our community.

Almost done…

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

OKSubscriptions powered by Strikingly

Apr 23 2018
Apr 23

Many years ago, I was going for a morning stroll in New Jersey with my dad. We walked past a complete stranger and my dad said, “Hello.” My parents are divorced and I lived (mostly) with my mom in Brooklyn, so I spent the majority of childhood in a place where no one says hello to strangers. I was bewildered so I asked him why did we just said hi to a complete stranger and he said...

Saying hello is easier than saying f*ck you.

That is truly what he said and I can honestly say, it is the one and only time I have ever heard Sheldon Rockowitz swear. He broke his polite demeanor to emphasize to me the importance of saying hi.

Fast forward 20 years. I am now a father and my four-year-old son is complaining that he has no one to play with. I point to the closest child his age and tell him to go up to the kid and say 'Hi, my name is Ben'. He did it and discovered the concept and value of initiating a greeting with a complete stranger. And he made a friend for the day at the playground.

Two years ago, we were on a summer trip in Montreal and hanging out in a playground. Like many parents, I was laying low on the sidelines, observing my child's interaction with other kids. Ben walks up to a kid on the swing set and says, "I am not sure what language to say ‘Hi’ in, but my name is Ben." Ben's natural ability to adjust his approach blew my mind because he not only found a way to communicate with a complete stranger who might not be comfortable speaking his language, but he also shifted his method based on what he knew - and this is equally important - what he didn’t know. Kids are the future, and they teach us valuable lessons all the time.

Ben taught me..

No matter how difficult or challenging it is to approach someone, you should still find a way to say to hi, to be the first one to launch a connection. And you should do that even if you’re not sure of what the outcome will be. Taking the risk means you’ll gain something; doing nothing adds nothing new.

The Drupal community and software needs to say "Hi" and make people feel comfortable

Improving the evaluator experience has become one of our communities initiatives. There are many approaches and plenty of awesome people contributing to improving this experience. Providing a single command to install & run Drupal is critical, however I feel that we the Drupal Community should not lose sight of the importance of saying "Hi" and making someone feel comfortable who is installing Drupal for their very first time. It’s something that only takes a moment but works wonders in easing barriers - it acknowledges your presence and opens the door, ushering you in. Helping someone feel comfortable with using the command line can be a make or break user experience. I have a huge amount of faith that the Documentation working group will collaborate and continue to provide a first-rate getting started guide. I hope after the initial patch is committed, we’ll aim to further improve the evaluator experience by congratulating someone on installing a piece of fantastic Open Source software for their first time using CLI, which by the way, means Command-line interface.

Hopefully, we can even take the time add some cool colors to the below message.

For anyone that is already a command-line ninja, the above message would only be seen once, but I would never expect a command-line ninja to be executing `drupal quick-start` because they have already progressed in their journey to installing Drupal using a recommended local server setup.

Making it easy for people to learn more about our community and our principles

Our community is massive, and Drupal.org is overwhelming. Many people have acknowledged the problem and Drupal Association's new Drupal.org homepage is now addressing personas to better direct visitors.

We have a great community and the below saying is part of Drupal's credo.

Come for the software, stay for the community

This was my experience ten years ago when I first downloaded and installed Drupal. I feel that we should recognize the comma between the "Come for the software" and "stay for the community" because it represents what I am going to call, "the journey from the code to the community." There is a problem in our code; it is not a technical one; it is content one. We need to value and think about every user experience and the messaging and content around every new feature we add to the software.

We are collaborating on creating the single most important piece of content in our community, it is our "Values & Principles" I want to ask you the community…

Where should our values & principles live?

We can learn a lot from other communities

Before DrupalCon Nashville, I blogged about the potential threat of WordPress. At DrupalCon Nashville, I attended the Community Summit, which was also attended by two amazing members of the WordPress community, Andrea Middleton and Jill Binder. They shared with the Drupal Community how WordPress organizes meetups and camps. Andrea and Jill demonstrated to me that Open Source communities should always collaborate and share ideas and solutions. Personally, in the Open Source world, I have come to view all competing projects as sibling projects.

WordPress has principles and they live in their code more specifically the software's admin user experience. Their approach is very straightforward and begins with a clickable logo in the upper right-hand toolbar which opens to a What's New, followed by Credits, Freedoms, and Privacy.

WordPress About Section

WordPress About Section

To use a Picasso’ism, we need to do more than copy this approach; we need to steal it (in a friendly way) and make it our own solution.

Community in Code

Before I even start discussing any possible approaches, I need to quote one of our values to help guide this discussion... 'embrace change'. In other words, here is my idea of how we get started: Let’s work together to make it better.

Personally, I feel that limiting this content to three key pillars of information is a better way to consolidate our information.

The three pillars I recommend are...

  • Getting involved in our community

  • Recognizing who is involved in our community

  • Discover our community’s values and principles

The Drupal logo should be the same drop logo as the one on Drupal.org. Wherever possible, we should pull content and design elements from Drupal.org.

Getting involved in our community

I am betting that aside from our values and principles, this going to be the most challenging content to create because it requires aggregating content from 100's of Drupal pages into a single page. Taking the new personas from Drupal.org's recently redesigned home page could help orient new and existing members of our community. For example, we should encourage developers to contribute code, marketers to help coordinate events and materials, and agencies to contribute and/or sponsor development.

Another feature we should learn from Wordpress is to promote upcoming Drupal events, especially DrupalCons, since we now know these dates so far in advance. Ideally, we should pull in a feed from Drupical but realistically we need to start with an MVP (Minimum viable product) approach and just link resources like Drupical, the Drupal Association newsletter, Drupal Planet, and Drupal Groups.

There is plenty of other content we can add to this page. We should focus on the immediate messaging and accept that creating and maintaining this type of content is an iterative process.

Who is involved in our community

I feel this could be a game-changing feature because we can visually give credit to core contributors and contributing organizations. We need to push ourselves on this page to give credit to everyone while inspiring new contributors and organizations to get involved.

We also need to highlight core initiatives; this will provide a clear statement that the "Drop is always moving" and we are continuously seeking to improve the software and grow our community.

Most people know that I am a passionate advocate of pushing people and organizations to support the Drupal Association. I also respect that some people have reservations about this. One thing I want to push for is that the Drupal Association staff deserves equal credit for their contributions to supporting Drupal.org and the Drupal community.

I am envisioning that each contributor has a card that says...

{name} does {work} for {project} and {works for company} and they like {something}.

Citing what someone is doing acknowledges their contribution. Recognizing their company (aka sponsor) helps improve sustainability. Allowing contributors to append something personal to their card adds a "being human" aspect to each profile. Further, recognition puts a name to the work, cultivates accountability and fosters a healthy sense of competition, it drives us all to do better and connects us in a way that anonymity never accomplishes.

For example, my card would say...

Jacob Rockowitz (jrockowitz) maintains the Webform module and likes Portuguese Water Dogs.

BTW, I wouldn't want my card to include a company because no one is currently sponsoring my work. Maybe in a (much) later iteration, we could add a 'sponsor my work' link to my card.

Let's admit that there is no better advertisement for a contributing organization than their company's name, logo, and URL in the software. BTW, I only want to see organizations that sponsor (aka pay or employ) an individual person contributing to Drupal, highlighted in core, hence why I want to call them a "contributing organization" instead of a "sponsoring organization".

I found it a little disconcerting that all the diamond sponsors of DrupalCon Nashville were hosting companies, but not all these hosting companies have an equivalent amount of developers contributing to Drupal core and contrib. If they have enough money to appear on stage at DrupalCon promoting their product, shouldn't they also be committing similar funds to writing the code?

Understanding and recognizing who is contributing to Drupal is a very challenging subject matter.

For now, I would like to clearly distinguish that "sponsoring organizations" are giving money to Drupal to get their name recognized and help to fund the Drupal Association ongoing work maintaining Drupal.org and the community, while "contributing organizations" are contributing resources, money and people to help support the ongoing development of Drupal. It is important to note that many companies sponsor and contribute to Drupal.

The question is not should they contribute, but how they contribute.

Discover our community’s principles and values

Our value and principles are still in alpha releases and they will be ready when they are ready.

I look forward to helping add our value and principles to this new user experience to Drupal core. At the same, it’s important that we don't rush the finalization of our values and principles.

I don’t have any strong opinions about our values and principles except to keep it simple. My friend, Kaleem Clarkson, made me realize that our written values and principles are just words on a piece of paper or a computer screen, which are meant to guide our community. Ultimately, it is what we do and how we interact within our community that make these words a reality. Our behavior is the true barometer of our values.

How can I help make this happen

The actual technical implementation of a clickable logo linking to three tabs is definitely a lot easier than any core initiative. I am 100% committed to making this happen. I know it is going to require several discussions and few iterations.

One of many valuable lessons I learned at Adam Goodman's Teamwork and Leadership Workshop was that it’s okay in Open Source to have an exit strategy, and it’s something that can even help the community. My exit strategy for this proposed "micro-initiative" is that I am committed to seeing a stable implementation in core while clearly stating that people will need to contribute and take over future iterations.

Getting some initial feedback

Please post comments below. Hopefully, everyone’s feedback can help me better define the problem, solutions, goals, and even the implementation. Once I have enough information, I will follow up by creating the needed ticket on Drupal.org.

Conclusions

I want to sell this idea to our community, and yes this may sound cliche, but our values and principles statement should be our Statue of Liberty; what followed the gift of the statue was finding a place to put it and an equally monumental effort to fund a pedestal. The most important part of this analogy is the Statue of Liberty represents freedom and is always saying "Hi" to new people entering into a safe harbor in a new place. Regardless of what language you speak, she’s greeting you, ushering you in, letting you know you are welcome and you have value. I’ve lived in New York City my whole life - her presence never ceases to inspire.

Statue of Liberty

Statue of Liberty

Finally, the one thing we, the Drupal community, should always seek to improve is how we...

Say “Hi” and welcome everyone to our diverse and inclusive community.

Thank you, everyone, for your feedback.

I have created a Google Doc scoping out the overall idea and have begun working on figuring out how best to proceed in adding this to the 'Drupal core ideas' issue queue.

Almost done…

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

OKSubscriptions powered by Strikingly

Apr 02 2018
Apr 02

Recently I read Why is Drupal now the second most-hated platform behind SharePoint? followed by the predictable Reddit discussion trashing Drupal. Every time I read someone's negative, yet reasonable, criticism of Drupal, I can't help but rephrase Winston Churchill's famous quote about democracy in the context of Drupal and Open Source.

Many forms of Content Management Systems have been tried, and will be tried in this world of sin and woe. No one pretends that Drupal is perfect or all-wise. Indeed it has been said that Drupal is the worst Content Management System except for all those other solutions that have been tried from time to time…

Churchill's defense of democracy came at a time when the notion of democracy was under a direct threat. Drupal and Open Source are not imperil in the same way, but the lesson Drupal and Open Source can learn from history is that it is essential to recognize, respond, and adapt to potential threats. Ignoring problems is the worst thing anyone can do.

Introspection and discussion is a significant part of our process to improve and affect change within Drupal. I am looking forward to Owen Lansbury's DrupalCon Nashville presentation called Have We Reached Peak Drupal?. I have seen a preview of his presentation and it puts Drupal’s current state into perspective while also looking at its future. If you want to learn more about the discussion around "peak drupal" you should also check out Dave Hall's blog post, "Drupal, We Need To Talk."

While building and maintaining the Webform module for Drupal 8, I have thought a lot about the future of Drupal and the Webform module.

How do we increase Drupal's adoption?

I no longer feel adoption is a Drupal 8 specific issue but rather it’s a general recognition that the CMS market is shifting and Drupal is adapting to it.

Drupal is no longer for blogs. I myself moved my website from Drupal to a SAAS based page builder solution, called Strikingly. Drupal is for more ambitious digital experiences and for every small Drupal 7 website that moves away from Drupal, we hopefully gain a more substantial and ambitious Drupal 8 website. Still, in this day and age, the fact that Drupal's usage statistics have been relatively flat for the past few years is troubling. Content Management Systems is a competitive market, and if a CMS's stats are not growing, it is essentially viewed as dying.

I don't feel Drupal is dying but I do know it needs attention. And considering how much passion and energy I have put into the Webform module for Drupal 8, I feel adequately informed to say that I do see some writing on the wall, and it says that...

Drupal needs to significantly up its game and adapt.

Yes, I have experimented with promotions and encouraging people to contribute back to Drupal within the Webform module. Before I started any of these experiments, I put a lot of energy into upping the Webform module's game by making sure that Drupal's Webform module competes directly with the other big proprietary and Open Source form builders. The Webform module strives to provide an out-of-the-box experience that is welcoming and demonstrates the real power behind the Webform module which are Drupal's API's and community. For example, including a list of community provided Webform add-ons helps people know there is a community contributing code and ideas. Webform might be the only module that includes help videos within the user experience. To me, the most important aspect of these videos is that I am able to put a voice and person behind the code which assures someone that there is a maintainer and a community that support this project.

Drupal needs to start showing the people behind to code.

Yes, Drupal is targeting enterprise website and organizations, but people are writing the code. Every person and organization contributing to a project should have their profile picture displayed on the project page. Right now, all I can do is beg that we figure out how to support videos on a project page so that our code can finally have a voice. The best example of why video is important is sitting on Drupal.org homepage and you can watch it below.

When it comes to Open Source Content Management Systems and form builders, WordPress is our most direct open source competitor, and we should look at the WordPress community to see what approaches work and what approaches don’t.

WordPress' growth is huge

WordPress' usage stats have skyrocketed and WordPress now powers 30% of websites. I feel that it's possible to boil down the success of most Open Source software to three things, people, code, and money. Simply put, successful Open Source projects are built by a community of people who write good code while having the resources to maintain and improve the project. "Resources" is a nice way of saying "money" which translates into people being able to make a living while contributing to a project. Money should not be considered a dirty word in our community. Just as the "Free Software" had to rebranded as "Open Source Software," we have settled on using the word "sustainability" instead of "money." We have to be realistic - people, code and money are all important elements and they all benefit and depend on each other to function best. Without any one of those elements, the other two suffer - each one is dependent and essential to the other.

WordPress has proven that they have a sustainable ecosystem because people are allowed to charge for plugin support. Before I go any further, I must emphasize that I am against charging for Drupal modules, yet I am open to any other approach to making Drupal more sustainable.

So WordPress has money and community, but frankly, some of their code is getting a little stale and needs to be reworked. This similar problem led to the Drupal community's major rearchitecting of Drupal's underlying codebase and the release of Drupal 8. WordPress currently has a considerable amount of technical debt, but they have to community and resources available to fix it.

Good code requires developers with resources

WordPress is becoming more ambitious

The most immediate example of the WordPress community fixing and significantly improving their product is the soon to be released Gutenberg page builder, which I was able to test drive in three clicks. The experience was nothing short of amazing. WordPress' Gutenberg page building experience is nothing new but every major plugin installed on my test site was immediately integrated into the user experience; adding a form to a page was two clicks. Gutenberg has the potential to dominate online page builders. At DrupalCon I look forward to learning more about what's possible with WordPress 5.0. I am willing to bet that form builders and fieldable entities are next.

WordPress has several powerful form builder plugins available, and few of them are earning serious revenue. I have spent some time looking under the hood at WordPress' form builders, and each implements its own Form API and data storage API. WordPress does not have anything like a Field API or Views, which is the backbone of Drupal's ambitious digital experiences. It seems fairly obvious that if a few WordPress form builder plugins combined their duplicate efforts, they would be able to create something similar to and as powerful as Drupal's Field API and Views. They have the people and money to do it - they just need to write code.

Drupal is no longer intended to be scaled down for small blog sites, but WordPress has the momentum to scale up to larger enterprise sites.

Drupal is already ambitious

Drupal is the market leader when it comes to building digital experiences for large websites. Every single Drupal core strategic initiative which includes API-first, Media, and Workflow are working to make Drupal even more ambitious. The only thing that is slowing these initiatives is resources (aka money, which should not have a negative connotation).

I met with several of the coordinators behind these initiatives. Across the board, they identified the need for faster feedback from Core Committers, citing that a lack of Committer time was often a barrier to the initiative's progress.

-- Dries Buytaert

Drupal has a huge community of developers striving to make it better. Most people are contributing in their spare time or as a secondary task to their job (which pays them money). Most people value and understand the need to contribute to Open Source, but the bottom line is that there is a finite amount of energy that can be committed when you can't be paid to do it. And yes, Open Source has to still contend with the mindset "why pay for something that you can get for free." Changing this mindset is a much broader and challenging discussion.

My experience with clients that value Open Source is that they have no problem paying for tangible features and improvements to Drupal. The challenge that I have seen is hiring and paying someone to contribute back Open Source can be awkward...

Paying Open Source developers is an awkward transaction

Frankly, I’m at a loss when someone is trying to pay for feature enhancement to the Webform module. From my perspective, as a module maintainer, it’s hard to assess the potential client's seriousness. Here are some of the questions I find myself asking:

  • How much do I charge?

  • Are they assuming that my hourly rate is less because I like working on Open Source projects?

  • Are they okay paying for automated tests?

  • What does the agreement look like?

  • How do I phrase all work completed will be considered Open Source?

Keep in mind hiring anyone is a little awkward, not to mention time-consuming, and this why freelancer sites like Upwork are trying to make this a little more comfortable. One very personal issue I have with sites like Upwork and BountySource is that these sites have a process that can create bidding wars which can become a race to the bottom vs. the merits and value of the provided services.

The gold standard for dealing with awkward transactions has to be Airbnb because they figured out how to make people comfortable sleeping on other people's couches. Before Airbnb, my experience staying at bed and breakfasts was a disaster - one particularly nightmarish stay resulted in me having an asthma attack because the proprietor forgot to mention that they have cats.

The most immediate lessons we can learn from Airbnb are:

  • A middle man can make an awkward transaction more comfortable for both parties.

  • Presentation is key - Airbnb did not start taking off until they helped improve the overall photography of their listings.

  • Rating and comments can make both parties more comfortable and remind people that they need to be kind to each other.

If you are curious to learn more about the not-so-secret sauce of Airbnb, you should check out the How I Built This podcast with Airbnb: Joe Gebbia.

Improving the sustainability and figuring how to handle awkward transactions is going to take a lot of experimentation. The most immediate thing we do need to do is accept that these discussions are going to be uncomfortable. And when we accept that about both ourselves and the other parties, when we realize that we’re all fallible, we can shift a bit at a time, learning as we grow and always trying to keep our eye on the prize - we’re trying to make something great even better. When we lay the groundwork as a safe place where the overarching goal is attempting success, over time discomfort wanes and growth can take its rightful place - the front seat.

We need to step outside our comfort zone

The general reaction I saw from my brief attempt to make the Contribute module a dependency of the Webform module made me realize that people are uncomfortable with change and yes, the dependency became awkward. The concept of finding one's comfort zone with Open Source is a tricky challenge. The Open Source community is vast, and every project or even the code base requires a different approach; every single issue queue is a different experience.

The moment we can acknowledge that something is uncomfortable we can get past it.

I am going to keep making myself uncomfortable

My approach is just to keep pushing myself into more situations that make me uncomfortable and to just work through them. Because the only way to get through something is to go through it, to experience it - not avoid it, not go around it but to go through it. In the last year, I have found my groove for speaking at Drupal events, and I do my best to attend any Drupal camp and meetup in my area. It didn’t start out that way, but over time and through actual experiencing, I’ve become more comfortable and confident. I am invested in the Webform module because forms are the gateway to user interaction and engagement on a website. I built the Webform module to compete with enterprise form builders while providing the flexibility and openness for Drupal.

If I genuinely want the Webform module to compete outside the Drupal ecosystem, I have to start reaching outside Drupal and maybe even the Open Source community, and begin to use the Webform module as a way to introduce people to the Drupal community and Open Source.

Growth and diversity in the Drupal Community and Open Source is not going to happen in the code; it requires outreach.

Reaching outside our community to increase growth

If we want to see Drupal grow in the enterprise market, we have to seek out new opportunities and clients. There is no question that Drupal is being used by organizations to build ambitious digital experience. There are always more untapped opportunities out there.

A few weeks ago, the team at Nextide (www.nextide.ca) gave me a demo of their workflow engine/solution module called Maestro which leveraged the Webform module. There is a core initiative for improving Drupal's content moderation and workflow which is going to make it easier for content authors, reviewers, and publishers to manage content - Maestro's workflow engine/solution is for managing complex business processes. It was hard for me to fully understand these differences until Nextide walked me through their "Insurance Quote Request" demo site. A webform is being used to collect insurance quote requests, which triggers the complex business workflow of connecting with underwriters and allowing applicants to select an insurance quote. Besides just seeing another example of an excellent module available for Drupal 8, their demo showed me how Drupal with Webform and Maestro could tap into an entirely new market/sector… insurance rate quotes.

Drupal, the Webform module, and our community are building tools that can solve challenging problems, and we just need to get out there a demonstrate to people its potential. My post-DrupalCon resolution is to try to speak and present outside the regular Drupal camp/event circuit and see what happens when I use the Webform module to introduce new organizations to the potential of Drupal and Open Source.

For Open Source developers, we are in a fantastic time because everyone who has a general understanding of technology can appreciate Open Source.

Open Source equals opportunity; with a responsibility to share it and inspire others.

Reaching outside our community to increase diversity

If we want to improve Drupal's adoption, we need to start talking to new markets and sectors. At the same time, if we're going to grow our community we need to start talking and including new people. We need to create an environment that fosters and encourages speculation, ideas as well as mistakes and wrong answers. If we don’t have a place where that can happen, we can’t uncover the solutions and the right answers.

Palantir’s recent blog post Making Inclusion Happen Through Mentoring is completely inspiring because they are trying to solve one of the biggest challenges in the tech industry.

Palantir's Inclusion Initiative is an effort to make the Drupal community more diverse and inclusive by mentoring students and introducing them to everything Drupal has to offer.

If I am going to advocate for more people to contribute, for contributors to have a voice within Drupal the software, and pushing for us to starting targeting other markets, inclusion and appreciation of the need for diversity, than that is something that I need to think about and include as part of this process.

Conclusion

This blog post started out with a recognition for what we have and my sincere desire that we keep pushing ourselves to improve it. I am going to keep experimenting and trying new approaches. It’s what I do - I don’t know any other way. While writing this blog post, I have discovered what the first slide for my Webform presentation is going to be for people who are new to Drupal and Open Source.

Open source is not just about writing and using free code; it is about the right to share and change ​code. And change has a reputation for bringing about some amazing things.

Case in point: You. Here. Now.

Mar 14 2018
Mar 14

The Contribute module left a bitter taste in some people's mouths, and some people comments were a little a bitter.

Figuring out how to improve the sustainability of Drupal needs to be an ongoing discussion with a gradually evolving approach. It is important that Drupal and every Open Source project has an ongoing discussion about sustainability where everyone can share their views and experiment with new ideas and approaches.

The Contribute module is an experiment that ignited a discussion. It is important to recognize what works and what doesn’t, acknowledge and learn from mistakes, and continue to have this discussion. Sure, there will be varying opinions and results, but the discussion must always be permitted to happen.

My first mistake: The Contribute module is definitely not a technical dependency

The Webform module doesn't depend on the Contribute module to function properly. Honestly, I did not expect that adding this dependency would be so disruptive. This was my first mistake... adding any new dependency is disruptive especially if someone is managing a large multisite installation.

Conceptually, the Contribute module's message is for the broader Drupal community. This message is originating from my work on the Webform module, therefore it should have stayed in the Webform module. In time, I hope this message gradually works its way through the Drupal core issue queue and reaches the entire Drupal community.

My second mistake: Not fully thinking through my approach

How people interact and communicate in online communities is interesting (to say the least). The truth is people say and act in ways that they would never do in person. I am a born and raised New Yorker, which requires a thick skin to defend yourself, yet at the same time you need empathy to get along with so many different groups of people.

My first mistake was adding the dependency; my second mistake was including people's Drupal.org user profile pictures without explicit permission. Once this was brought to my attention, I immediately removed this feature and apologized.

My approach to highlighting core contributors was copied directly from WordPress. I would guess that WordPress gradually evolved this concept and implicitly got permission as they added contributor profiles. There is a lot that the Drupal community can learn from the Wordpress community. We should look outside the Drupal community to see how other communities are working to solve the challenge of sustainability.

People are going to make mistakes along the way

During this journey, there was a comment about being 'horrified' to have it implied that someone would support the Drupal Association (and the Contribute module). I am not active in the Drupal Association, but I can't watch people continually criticize the Drupal Association. The Drupal Association is a team of people whose sole purpose is to support and grow the Drupal community. They are going to make mistakes along the way. At the same time, everyone in the Drupal Association is approachable and genuinely cares about Drupal. Every month at the NYC Drupal meetup, I share a 'Drupal' beer (or two) with Neil Drumm ( drumm). It seems very extreme to be 'horrified' to support an organization that someone as awesome as Neil is working for; which is ultimately us… the Drupal community.

I think the biggest challenge for the Drupal community and the Drupal Association is evolving Drupal's governance and sustainability.

Who, what, where, and when should we be talking about governance, sustainability, and community

Governance and sustainability are critical to a healthy community. How a community works and supports itself needs to be open, transparent, and welcoming to people outside the community.

Yes, I think this conversation begins in the software. The message within Drupal should be concise and direct. A secondary but fantastic benefit to starting this conversation in the software is that Drupal's user interface would then allow us to translate this message into every language in the world.

Some people argue that they should be responsible for having this conversation with their clients and not the software. This is the current approach in our community; where Agency A pitches Drupal to Company B and Agency A is responsible for Company B's engagement in the community. In many cases, Company B's participation stops at Agency A, and Company B has limited or minimal involvement with the Drupal community, even though in many instances Company B will use Drupal longer than it works with Agency A.

My third mistake: Not talking about supporting the Drupal community with my client

Personally, I did limit Memorial Sloan Kettering Cancer Center's (MSKCC) initial involvement with the Drupal community. I was new to the concept of Open Source and Drupal; I said to MSKCC, "Hey look at this amazing 'free' software, you should use it". It took me six years to finally ask them to them to create an organization profile on Drupal.org and another two years to ask them to become an organization member of the Drupal Association. Not immediately understanding and explaining the importance of being a member of the Drupal community when I introduced MSKCC to Drupal is my third mistake.

We need to collectively start asking our clients to be contributing members of the community.

As an experiment, I went through a bunch of the top Drupal agency's client list and case studies, and a large majority of agency clients that are using Drupal are not organization members of the community or the Drupal Association. Some companies are not ready to contribute code to Open Source, but every company has some fundamental appreciation for Open Source because they are relying on it for their website. But a basic understanding of its value vs. participating and in a sense, owning its growth - i.e. contributing - are two potentially vastly different matters. Most companies would have no problem creating an organization profile on Drupal.org which would also help them recruit Drupal developers. The problem is that as a community we are not asking our clients to be active contributing members of the community.

Everyone should encourage their clients to be a member of the Drupal Association because it strengthens the community and gradually makes it possible for these companies contribute something back to Drupal. At the very least we can have all the Fortune 500 companies that use Drupal listed on Drupal.org with a Drupal Association membership badge that says they support Drupal.

Who should be contributing to Drupal?

The answer is everyone. One person reasonably commented that 90% of the people using Drupal would never contribute anything back. Right now, I think this is completely true. It seems absurd that only 10% of our virtual community is contributing code or are members of the Drupal Association. I can't imagine a physical community surviving with only 10% participation. If, as a community, we can get another 10% involved, it would significantly change Drupal’s trajectory and velocity. And that’s only an additional 10%.

If we want to grow our community, we need to examine it.

Is Drupal written by developers for developers?

Drupal is a developer-centric application. This is our biggest strength and weakness. Drupal has so many passionate eyeballs looking at the code and our security team is top notch. At the same time, developers can lose sight of the end users/clients.

The developer-centric mentality around Drupal drove most of the criticism around the Contribute module not being a technical dependency. Someone went as far as stating that the Webform module should also not congratulate and offer people help when getting started using the Webform module. I disagree - making sure that a new user has a positive experience and feel that they are part of a community where everyone is here to help and contribute is essential to the growth and sustainability of Open Source and Drupal. This most basic approach can’t possibly be viewed as negative - think of when you enter a store and someone says, ‘Hi, welcome to (fill in the blank). Can I help you find anything today?’ or when you enroll in college and you’re in the admissions office - someone says, we’re so glad you chose our university, let’s get you started - what are you thinking about majoring in?’ It’s a fundamental way to bring people in and let them know their presence, needs and input (and output) are a desirable thing.

Drupal is for everyone

We need to say 'Hi' and always welcome new users. I welcome new users to the Drupal community every week in the Webform module’s issue queue. Saying 'Hi' to someone for the first time is hard, and we are as a community need to discuss how we should be doing this. Every welcome contains a new potential opportunity to see growth.

Having a discussion without controversy

I believe the Contribute module's message, "The question is not should you contribute, but how can you contribute" should be part of core but it will take a major discussion, followed by a lot of work with some time and bits of patience to make it happen.

For me, the most immediate place to communicate with people using the Webform module is within the actual software.

The Webform module currently includes an optional 'About' section. I have decided the Contribute module’s message is more important than promoting the Webform module or myself. The Contribute module dependency has been removed and its message moved into the Webform module. Developers can easily disable the Contribute section via the UI (/admin/structure/webform/config/advanced). The Contribute section of the Webform module will give us an opportunity to evolve this message, get feedback, and continue to discuss this message in the Webform module's and Drupal core's issue queue.

Webform: Contribute

Webform: Contribute

For the individual responsible for the 200 multi-site installation, I am genuinely sorry that the Contribute module was more than a brief or straightforward discussion.

The ongoing discussion about sustainability is not a simple one, and I look forward to talking about this with everyone at DrupalCon Nashville.

Almost done…

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

OKSubscriptions powered by Strikingly

Feb 12 2018
Feb 12

Yes, I am a listening to everyone's feedback and second guessing my decision to make the Contribute module a dependency of the Webform module.

I was explaining to my 12 year old, Ben, the pushback I am getting around making the Contribute module a dependency of the Webform module and how most people agree with the Contribute module's general concept and message but are unhappy about how and where I placed it. Ben shrugged and says "So basically you are holding up a protest sign, people are agreeing with it but because it is inconveniencing them and they are upset at you and want you to remove it".

So the Contribute module is a protest/political statement; I am okay with admitting that. Many of the expressed concerns are immediately addressed by the fact that there are three different mechanisms to remove the dependency. The beauty of open source is that, if you don't like something, you have the freedom to change it.

For anyone truly worried that the Webform module will indefinitely depend on the Contribute module, it’s worth noting that all protests, political statements, revolts, and revolutions have to end at some point (aka release).

For the time being, however, I am going to keep maintaining the Webform module as well as working on (and defending) the Contribute module.

The Contribute module is not going bring down your website

A few people have expressed concerns about the Contribute module being unneeded and fear it is posing a security risk. Considering people are trusting my 10000+ lines of code in Webform module on production websites to build forms and securely collect data, this seems a bit extreme. To my mind, what seems like the biggest security risk in the Drupal community is unmaintained and unstable modules running on 100,000's of websites. The Rules module is a great example of key Drupal module that is still in alpha releases while being used on a production website. People need to contribute and help get out a stable release of the Rules module. Yes, I think challenges like this needs to be communicated directly in Drupal (the software), especially when people are running alpha releases of software on a production website.

Getting people involved to produce a stable release of the Rules module should be communicated directly in Drupal (the software).

Adding this dependency is going to destroy Drupal's ecosystem.

I thought some people above brought up some really good points about everyone in Drupal wanting to do something like this, but everyone choosing a different message (module) and how that would really destroy the ecosystem.

-- http://dgo.to/2936020#comment-12472445

Yes, if every modules maintainer started to include different messages in their module things could get out of hand - I get that. It’s why I decided to build a dedicated module that conveys this extremely important message, "The question is not should you contribute, but how can you contribute." This message will hopefully strengthen Drupal's ecosystem.

The Webform for Drupal 8, which I have built from scratch on my own time, is currently one of the most well-maintained, well-thought out modules that provides a user experience welcoming new users to our community. The energy and passion that I have committed to this module does nothing but strengthen Drupal's ecosystem

Not everyone can/should support the Drupal Association

It seems silly that I have to continue arguing that everyone should support the Drupal Association. Every Drupal Association individual and organization membership, helps Drupal reach more people and communities. Improving diversity in the Drupal and Open Source community is only going to happen with outreach to underrepresented groups and communities...this requires money and people getting involved.

The argument that not everyone can afford to pay the membership fee is a reasonable one. Hopefully those of us who can afford to pay the membership fee will pay it and the DA can help poorer communities through outreach and scholarships.

Finally, acknowledging people's hard work and amazing contributions

One my key goals with the Contribute module is to remove the notion that Drupal is built and maintained by large organizations. Drupal and Open Source is built by individuals who may work for large organizations, but at the end of the day it is developers who write the software. The Contribute module is an effort to get individual Drupal users (and their organizations) involved in our community. Acknowledging core and project contributors as well as the Drupal.org staff is great way to showcase who is building and maintaining Drupal. It’s one step closer to accessing who we are - it gives it a name and a face, it invites us to get to know what’s possible, and who we’re working with.

The initial release of the Contribute module was simply meant to communicate the message that people should get involved by joining the Drupal community, becoming a member of the Drupal Association and contributing back to Drupal. Besides inspiring people to get involved, it’s important to acknowledge the people who are involved. Personally, I want to the say thanks to all of Drupal's core and project contributors. I know first-hand how important and valuable they and their work is to me and what I do.

Below are screenshots of the three new callouts in the Contribute module, which highlights Drupal core maintainers and coordinators, the Drupal Association staff and board of directors, and installed Drupal modules and theme contributors.

Status Report: Community Information

Status Report: Community Information

Status Report: Community Information: Drupal Core Maintainer & Coordinators

Status Report: Community Information: Drupal Core Maintainer & Coordinators

Status Report: Community Information: Drupal Association Staff & Board of Directors

Status Report: Community Information: Drupal Association Staff & Board of Directors

Should other module maintainers add the Contribute module as a dependency

This is a very tricky decision because some people reasonably disagree with this approach. At the same time, as contributors to Drupal we all struggle with the simple fact that we are part of a very small percentage of the community who is doing most of the work. The entire open source community is struggling with these challenges and change almost never happens without a strong push/statement. We can’t get answers if we don’t ask the questions.

Making the Contribute module a dependency is a statement.

If one or two key modules in the community were to even temporarily make the Contribute module a dependency for a release or two, it would help push our community to improve the messaging within our software and give visible credit to the people who are helping to build and maintain our software and community. And acknowledgment and understanding are key to growth. Not to sound totally preachy here, but the only thing we can say for sure is that change is inevitable, nothing can stay the same.

Personally, I am going to stick to my guns until DrupalCon Nashville. After DrupalCon Nashville, I look forward to tagging a stable release of the Webform module for Drupal 8, which won't include the Contribute module dependency.

The discussion will continue on Drupal.org

Even though some people disagree about how I have communicated this message; most agree with the message. I hope everyone can see that our code and software has the ability to communicate with every user and organization and it can be used to change people's mindset around contributing to Open Source. In the next week or so, I will be creating a core issue about the Contribute module and look forward to a productive and reasonable discussion. I care deeply about the work I’m doing here. I see it grow and change and want it to continue to do so. Each day gives us new opportunities to make it better and further its reach - it’s exciting stuff that warrants our attention and devotion. Call it protest if you will, but I like to think of it as opportunity.

Almost done…

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

OKSubscriptions powered by Strikingly

Jan 30 2018
Jan 30

Half of the people can be part right all of the time
Some of the people can be all right part of the time
But all of the people can’t be all right all of the time
I think Abraham Lincoln said that
-- Bob Dylan

I love these lyrics from "Talkin’ World War III Blues" because it reminds us that it’s impossible to get all of the people to agree on what is “right”. The best we can hope for is a fair and reasonable discussion followed by a compromise.

Two weeks ago, I published a blog post that stated the Webform module now depends on the Contribute module with a reasonable explanation as to why I was making the change. Some people aggressively pushed back about this approach, especially in the Webform module's issue queue. I completely agree that long-term change on what message is communicated as well as how the Drupal community presents itself in the actual software is going to happen in the issue queue on Drupal.org and at DrupalCon. The fact that people consider me promoting the concept of joining Drupal.org, becoming a member of the Drupal Association, and contributing back to Drupal an "ad" or "SPAM" is troubling. I view "code as content". I feel that the Drupal community and Open Source needs a push in a more sustainable direction and I’ve used the Webform module and my two years of hard work as a 'soapbox' to make an important statement, which is "WTF: What's The Future Drupal?

"WTF?: What's the Future and Why It's Up to Us

So I just finished Tim O'Reilly's book titled "WTF?: What's the Future and Why It's Up to Us" and in his book, he passionately talks about how Open Source has shaped the world we see today and the future we see before us. O’Reilly says that Facebook and Google would not exist at the scale they are today without Open Source because both platforms are built on an open source stack of software. To me, that’s huge. O’Reilly’s book explores the key defining technology moments in our past, and how technology in the future is going to impact the workforce, government, healthcare, and politics. We, the Drupal community, are defining a key moment in the evolution of technology and society - definitions that will impact our future and our kids’ future.

Drupal is defining the future

We are the largest open source community building the most tangible and accessible piece of technology available in the world. When I explain to people that Drupal builds websites and anyone has the freedom to use it - they begin to appreciate Open Source. Anyone in the world can use Drupal - they don't need to know how to code, there’s no credit card needed to buy an add-on. becoming a member of our community is the only requirement - and all are welcome. And when you consider all of the vital and useful things out there in our daily lives, most of which are hardly free, that’s pretty amazing.

Of all the Open Source projects out there, Drupal is the only place a completely non-technical person is welcomed with open arms. Everything we do comes with the GPL Freedom. There‘s no competition between projects or "paywalls" in our code. Anyone can use it. We are defining what a global universal collaboration looks like and every single person who has access to a computer understands that we make it possible for anyone to have the freedom to build any type of website or application. In this sense, when the Drupal community calls itself a community, it lives up to the broadest definition of the word.

The Drupal community needs to take the challenge of sustainability head-on

Sustainability has to be the biggest challenge facing the Open Source software community. We have proven the GPL and Open Source works. At the same time, we have seen developers burn out and projects become neglected. It all comes down people being able to make a living writing Open Source Software. There are amazing resources about getting paid for open source work and incredible collaborations discussing the challenges of sustainability.

So many of the approaches for funding open source have relied on a tech company/organization or even a fellow developer helping to crowdfund a project - it simply results in developers who appreciate open source paying other developers. Open source benefits everyone in the world and we need to communicate to all users, big and small, how important it is to contribute something back.

Drupal has potential to educate people about Open Source and change the world’s mindset regarding supporting Open Source software.

It may come as a surprise to many that everyone in the world is already holding Open Source software in their hand when they pick up their phone to make a call. Sure, it would be amazing if every Android and iOS device said "Built with Open Source" on the startup screen. And yet, not everyone can contribute to Android or WebKit. On the other hand, everyone can (and should) contribute to Drupal. Open Source is integral to so many resources in our daily lives but functions quietly in the background.

Changing the world's mindset about Open Source

Recently, my really smart nephew applied to college seeking a computer science degree and has no real appreciation of Open Source, which is both mind-blowing and troubling to me. To my mind, any potential computer science student should feel a responsibility to be involved in open source projects because Open Source is part of their education, craft, and profession. Also, students have the time and passion to make amazing things happen like Drupal.

Dries Buytaert's software powers a million important websites — and he built it from his couch (in college)

-- businessinsider.com

I can name a few others that come to mind but I think we’re all fully aware of students contributions to the tech world over the past 20 years.

Honestly, my nephew is still so obsessed with his video games that I’m not sure he would be motivated to go to a software meetup. If we began to change the world's mindset, his mom and dad might be the ones saying to him, "if you want to get into a good computer science program, you need to get involved in the open source software community". Drupal and most open source communities would welcome him with open arms and maybe even give him a slice of pizza and his first beer. But if we truly succeeded in changing the way the world views Open Source, my nephew would call this useful bit of advice not from not just his parents, but also his advisors, his friends and his daily interactions with technology. Ultimately, it would no longer be an issue - my nephew (and other computer science major/college-bound applicants) would already be informed because it would be integrated into his life from a variety of platforms and people

Everyone needs to be pushed in the "right" direction

Yep, I pushed my message in front of everyone in the immediate Drupal community of developers in the hopes that we can see the importance and need to push the entire world in the "right" direction. I apologize to people who are offended. My intentions have been, and remain, good. Of the many lessons, I have learned while contributing to open source is to “respond to criticism with kindness" which is I am saying "WTF Drupal?"

I like to summarize What's the Future Drupal by stating three key points that I hope we keep in mind while we change the world's mindset when it comes to Open Source.

  • Everyone in the world can understand, appreciate, and contribute to Drupal, which means we are the welcoming wagon to people learning about Open Source.

  • Everyone is here for Drupal "the software" and "the software" is our most important piece of content.

  • Drupal needs to communicate and represent the Open Source movement and challenges in its entire user experience.

For the person who just joined Drupal.org, or became a member of Drupal Association, or submitted a patch to the Webform module's issue queue...

You Rock!!!

What's Next for Me & Drupal

Well, I am done for now, and I’d like to go back doing what I do best, which is writing open source code, welcoming new members to the Drupal community, occasionally being preachy, and getting ready to present at upcoming Drupal Camps and conferences. All of these things are my ways of saying not What’s the Future Drupal (WTF) but rather, Drupal is the Future (DTF).

DTF? Drupal is the Future

Yes, I said it and I believe it. It’s why I’m writing this post and it’s why I work as hard as I do writing code, welcoming new members to the Drupal community, occasionally being preachy...okay, I think you see where I’m going.

Drupal is an amazing community with great leaders and passionate contributors who build and maintain software that is changing the world. We need to also change the world's mindset and commitment to Open Source software. The people we need to reach is not the developer sitting next to you and probably not even your boss, it’s everyone and it’s right now. More importantly, it is the future generation and their parents, maybe even their grandmas.

Finally, if your kid tells you they want to go college for computer science, please encourage them​ to go to a Drupal or a software meetup because they are always welcome and we look forward to meeting them. And if they’re not convinced, remember beer and pizza is an easy sell - most of the people will probably agree. The contribution part? I’m hoping we can make that one a no-brainer too.

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 2018
Jan 15

After spending the past year experimenting with promoting paid services, talking about sponsored features, and adding an about section to the Webform module, I learned a lot, from my experiments, including not asking for forgiveness.

"If it's a good idea, go ahead and do it. It is much easier to apologize than it is to get permission."

-- Grace Hopper

Importance of contributing to the Drupal community

Not enough people understand and/or realize the importance of contributing to the Drupal community. My last blog post discussed my hope of finding ways to help sustain my commitment and contribution to the Drupal community and ended by stating…

The question is not should you contribute to open source but how can you contribute.

Convincing people that they need to contribute

The challenge is convincing people and organizations that they need to contribute to Open Source. Funding is an ongoing challenge for the Drupal community The problem could be that people don't understand the importance and value of contributing back to Open Source.

Nowhere in Drupal's user interface/experience is our community and Drupal Association promoted and/or acknowledged. Core maintainers are only included in the MAINTAINERS.txt file, which only fellow developers can access. Drupal is not a product that can to be sold but we are a community with an association that needs recognition, support, and contributions.

The Drupal Association is the backbone of the community and everyone needs to be member.

Everyone needs to be a member of the Drupal Association

It’s surprising how many people and organizations are asking for support in the Webform module's issue queue who are not members of the Drupal Association. As another experiment, I thought of my top 10 list of showcase Drupal websites and most of them are not members of the Drupal Association. These are large enterprise websites that are not paying a few hundred dollars annual membership fee to help maintain the software and community that they depend on. And if we can't get a developer or company to pay a small membership fee, how are we going to show them the value of contributing to Drupal and/or funding core or contrib development?

Encouraging individuals and organizations to join the Drupal community

The Webform module now depends on the Contribute module.

Contribute module

Contribute module

Introducing the Contribute module

The Contribute module’s project page provides a complete explanation of the module’s goals and purpose. I wanted to isolate the concept of everyone contributing back to Drupal into a dedicated module because this is not just a Webform specific challenge. I think it’s important to emphasize that other modules can also depend on the Contribute module. Frankly, if some of Drupal's top 40 modules were to add the Contribute module as a dependency, it would clearly acknowledge the overall desire to change the Drupal user's mindset when it comes to contributing back to Drupal. It’s very important for me to point out that the Drupal community is not the few thousand developers and companies who contribute and value Drupal; our community is the one million sites using Drupal.

Preaching to the choir

This blog post is "preaching to the choir" because we are all active and caring members of the Drupal and Open Source community. However, we need to take it a step further. We must look beyond our code and talk to the people who are actually using our software. For Drupal and Open Source to succeed, everyone needs to contribute back to the community - we need to reach out to these users and organizations and communicate that their participation is not only welcomed, but vital and necessary.

Creating code before the discussion

Instead of discussing this idea extensively, I decided to just go for it. At the same time, I have been asking every single person I know to provide feedback. The general consensus is that the Contribute module is not going to offend anyone, but nobody can say if it can succeed in changing our community’s mindset. I don’t know the answer either but I do know that I want to ask the question, that I do want hear what others have to say and so I started this discussion using my best tool; thought out, clean, and simple open source Drupal project called the "Contribute module."

Learn more about the Contribute module

I look forward to hearing your thoughts.

Almost done…

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

OKSubscriptions powered by Strikingly

Pages

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