My level of involvement and interest in contributing to Drupal core has ebbed and flowed over the years. Some years I’ve found 1 or 2 others to partner with around a common goal and I’ve poured a lot of time and energy into accomplishing those goals (with mixed results). Other years, stalled issues and feelings of frustration and isolation reign supreme. Those times are not so fun. What I’ve discovered relatively recently is a way for me to contribute to Drupal core that brings balance and routine back to my contribution efforts. Instead of the dramatic and draining swings between “GO, GO, GO” and “NO, NO, NO”, I drop in, when I can, to the #bugsmash channel in the Drupal community’s Slack, and spend 10 or 15 minutes (sometimes more) on issue triage. In the #bugsmash channel, I have found camaraderie, encouraging and helpful interactions, and plentiful opportunities to help triage and close Drupal core bugs. It’s been rewarding and fun—and it fits quite nicely into my schedule.
Illustration by Caroline Liu.
The Bug Smash Initiative was created to focus on fixing known bugs in Drupal core. In order to resolve such a large number of bugs, the primary tool we use is issue triage—giving constructive feedback and updating issue metadata in order to make it easier for contributors and committers to know what could be done next. Issue triage (so I’ve learned) is a vital process for addressing the huge number of open bug reports in Drupal’s issue queue. Learn more about what bugs we’re looking at.
But what are these bug reports? And what do we do and not do with these issues? Many are quite old! Are they still relevant? Is there a duplicate issue that’s made better progress? Are there steps to reproduce the problem? Does it need a manual test or an automated test? Maybe there’s a patch but it no longer applies and needs a reroll. There are lots of reasons a bug report might be stalled and there are many ways to move an issue toward resolution and closure. Updating an issue so that someone knows how they can specifically help is issue triage and it’s a proven way to deal with a massive issue queue like Drupal core’s.
Issue triage is its own art and there are a lot of issues with the same kinds of problems. This is why I always have this documentation open when I triage a Drupal issue: Issue queue triage intro and comment templates. This incredibly valuable page provides guidance for Bug Smashers about how to triage an issue, what to do with security issues, and how to comment, update, and ultimately close bug reports.
I think the Bug Smash Initiative lends itself well to Drupal developers who want to contribute to Drupal core, but maybe don’t have a lot of time to devote to it. I have a daily task set up which reminds me to pop-in to #bugsmash and see if I can help with one of the issue triage targets. Sometimes I have time that day, sometimes I don’t. I help when I can.
If you do decide to drop-in, get acquainted with the initiative by heading over to the Bug Smash Initiative guide and read Working on the Bug Smash Initiative. This page explains how we work and how to decipher the very deliberate use of emojis in #bugsmash. It also has the meeting schedule (held every 2 weeks — and held open asynchronously for 24 hours to enable participation across all time zones). There’s a bit of a learning curve, but lots of friendly folks and docs to help you along.
Add new comment