The bar for reporting a bug to the Rails project can be pretty steep. You’re expected to carefully diagnose the problem, preferably propose a solution, include detailed reproduction steps, and all the other homework that makes it possible for a project like Rails to deal with hundreds if not thousands of reports on a yearly basis.

While this is a reasonable process for collecting actionable reports that a small group of contributors can reasonably triage, it’s not a great process at all for learning about all the the potholes, the roadblocks, and the roundabouts that make your journey that much more uncomfortable or take longer. That stuff just gets swallowed up by the sinkhole of grievances (have I exhausted the metaphor yet?! 😂).

So when Avdi took to air some of those grievances on Twitter, the natural thing happened that always happens when you feel your work is attacked: The core contributor group got defensive! That’s a mischaracterization! Where are the completed bug reports!? You know the drill, if you’ve ever worked on something, poured your heart into it, and then seen it criticized online. There’s that immediate, knee-jerk reaction of a sting. But it doesn’t have to sting.

“Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom” – Victor Frankl

We’re now choosing that response to be something different than the typical response to a perceived slight. Our response will be that of growth, and its essence is that Avdi’s frustrations are broad frustrations, they’re valid frustrations. They’re perhaps not yet in an actionable form, like we’re used to with perfectly described bug reports, but we can turn them into that! Together!

And even more, we can accept that Avdi’s frustrations are not anywhere near broad enough to cover all the frustrations. So we can ask for more! In a structured way, under a new paradigm of inquiry, and we can make Ruby on Rails better together. That sounds pretty good, no?

So that’s what we’re doing! We started a small group to involve Avdi, Betsy, and others who’ve expressed grievances or interest in those grievances to work together. And the first project to come out of this group is what we’re calling A May of WTFs. It’s a new category on the Ruby on Rails discussion forum, and it’s going to be a safe space for those WTFs you weren’t going to turn into formal bug reports. It’s going to be timeboxed to the month of May. And it’s going to run under the championship of Betsy Haibel. So I’ll let her set the terms of engagement:

We all lose time to “Rails WTFs.” Something goes weird in our Rails process, and we spend four hours frantically reading Stack Overflow before it finally occurs to us to restart Spring. Or we make one silly typo and it causes the autoloader to lose track of an entirely different class.

It can be hard to write bug reports for a WTF. When it’s difficult to understand what triggered it an issue, or what fixed it, nailing down a good reproduction seems impossible. And who wants to go to that effort when they’ve just spent hours staring at byebug and cursing computers?

This May, the Rails team is going to be tackling some of these WTFs – which means we need you to tell us about them! Send us your strangest Rails 6 stories, even if you don’t really understand what triggered them or remember how you fixed it. Provide as much detail as you can – but don’t worry over what you can’t. We’ll be looking through all of this for patterns that will let us improve Rails (or at least its error messages) for everyone.

So please, come join us in a May of WTFs. Help Betsy, Avdi, and everyone else who’s interested in transforming the raw energy of frustrations into gleaming patches to documentation, error messages, or even APIs. We’ll take WTFs as input and produce 💖 as output.