My last blog post thanked the collective's individual backers and supporting organizations for their financial support. Now I would like to break down how the collected funds were spent to tag the Webform module's latest release. 

To provide the most value to backers, I opted to track my time in five-minute increments in the hopes that the amount of work that goes into maintaining the Webform module can be better understood. Tracking these smaller increments also shows how solving a problem or providing support is a multistep process, which begins with triaging issues. 

Triaging the Webform module's issue queue has proven to be one of the most challenging tasks related to maintaining the Webform module. I have struggled with wrangling the issue queue, nudging people in the right direction, and now I am finally putting my foot down when I feel people are taking advantage of open source. Admittedly, I was getting burned out when dealing with people who did not appreciate the value of my open source work. Fortunately, I see now that many people value my open source work, and they want to see me compensated for my time. 

The overall challenge to wrangling the Webform module's issue queue is that everyone has different levels of experience in Drupal. Organizations are trying to build unique and complex digital experiences. If you combine this with the fact that we are an international community, the result is that issue queue tickets come in all shapes and sizes. Therefore, with each issue, I have to figure out the problem, priority, solution, and level of effort required to resolve the issue.

I am grateful the Drupal community has created a plethora of helpful documentation around our issue queues, including an issue etiquette/procedure page. Once an issue is triaged, the bug report, task, feature request, or support request needs to be addressed. 

By accepting that bugs are part of creating software, I feel it is equally essential to deal with them. It is best to squash bugs as soon as possible; therefore I want to provide a patch when I am first investigating most minor bugs. Most minor bugs require a one-liner fix. More significant bugs are typically related to a problem that spans multiple subsystems that are possibly conflicting with one another. 

For example, two minor bugs that were fixed recently include, read-only cross-page conditional logic was not working as expected (see Issue #3208926), and there was a regression with the wizard URL page tracking code (see Issue #3211736). The wizard URL page tracking code regression took 10 minutes to investigate and upload a patch, with another 5 minutes to do a final review before applying the patch and closing the ticket. Fixing bugs related to supporting the Paragraphs module tends to be more time-consuming, so I only provided an initial patch from an entity reference-related problem (Issue #3209462). 

It takes between 5 to 10 minutes to investigate the problem and respond to the support requests for most tickets. Still, with the fact that there are over 100,000 active installations of the Webform module, answering support requests can quickly become overwhelming. 

When I took over responsibility for the Webform module for Drupal 8, I did not know what to expect. Still, I was looking forward to the challenge of pushing myself to work at a different scale and in a very different context from my day job. My day job has a few people asking me questions and requesting help. Meanwhile, the Webform module's issue has hundreds of people looking for help. The existing issue queue submission guidelines foreshadowed the challenge I faced in handling support requests. The guidelines stated that there are not enough resources available to handle support requests in the Webform module's issue queue, and all support requests should be posted Drupal Answers. 

Over the past five years, I revised the issue queue submission guidelines and continue to route support requests to Drupal Answers. Still, people - especially new community members -  post support requests, which I do my best to answer, and then I nudge them to use Drupal Answers.

I love helping people and would like to respond to every support request, but support requests can easily consume most of my time commitment to the Webform module. Ideally, one day we could have enough collected funds to handle support requests. There are a finite number of bugs in the Webform module and a limited set of features that the Webform module can provide, but there is an infinite amount of support requests that only increase as more people use the Webform module.

Support is one of the biggest concerns around open source software. This is why I decided, along with the Webform module's Open Collective, to include the option to contact and pay me for support. Along with paying for help, I have advocated for sponsored features. 

The Webform module for Drupal 8/9 is very feature-rich. At first, I was aiming for feature parity with the Webform module for Drupal 7. Then I sought to match the standard feature sets provided by most enterprise form builders on the market. Generally, I was open to saying "yes" to any feature request that provided value to community members. Occasionally, an organization would sponsor a feature, and I would write a blog post acknowledging their support. 

It is reasonable to conclude the core Webform module has enough, maybe even too many features. Fortunately, with Drupal, everything is extendable; this is why there are close to 200 Webform add-on modules. Therefore, I am directing people to create or sponsor a dedicated contrib module for most new feature requests. 

At the same time, it is essential to enhance and improve existing features and functionality in the Webform module. For example, I have been working to improve the user experience when translating a webform, and it was worth adding HTML editor support to the webform translation edit form (Issue #3204180). I have also started to add "multipart/form-data" to support the remote post handler (Issue #3212237). Finally, I am gradually seeing organizations with platforms that rely on webforms built on Drupal 7, which are now being migrated to Drupal 9, possibly need performance improvements to improve the scalability of having 1000's of webforms shared by hundreds of users. 

I am glad that Drupal's issue queue categorization options include 'Tasks' because sometimes things related to the Webform module are just a task. Tagging the latest release of the Webform module is around a ½ hour task, which includes performing a full code review, release note generation, and finally creating the release. 

Because I am trying to limit my time spent on any ticket to under an hour, I have avoided fully supporting Drush 10. To properly support Drush 10 moving forward, we should drop support for Drush 8, and this task will take a few hours. 

An accessibility review is another crucial task. Two years ago, I managed to do an accessibility self-audit. Still, the reality is collected funds could be used to get a professional accessibility review, or an organization could contribute resources to do the review. Accomplishing the bigger tasks and fixing challenging bugs related to the Webform module will require significant resources; I am not sure individual contributions can support these more substantial tasks and challenges. 

Let me emphasize that I never expected to collect over $10,000 from the combinations of individual backers and sponsoring organizations. It makes sense the majority of the backers are individuals who understand and appreciate the Webform module. At the same time, organizations profit the most from open source software by not having to pay licensing and support fees. I have seen digital agencies doing Drupal-related projects for hundreds of thousands of dollars, and they give very little back. It is hard not to shame these organizations for not understanding the value of supporting open source. We need to figure out how to nudge and provide incentives for these organizations to get involved. My next blog needs to explore how the Webform module's Open Collective funds could be spent to get more organizations involved. 

For anyone considering joining the Webform module's Open Collective, you now can see that even a five dollar a month contribution helps to resolve a bug or support requests that could be impacting your project or your neighbors' project. For those of you who give, thank you and for those who don’t, please consider it and what the Webform module’s worth is to you. 

And as always, thank you for reading. 
---