Over the weekend, I decided to change my theme from the WordPress TwentyThirteen to TwentyFifteen. I switched mainly because I wanted a more accessible theme, and also because I was getting tired of looking at the Thirteen one. Another nice feature was the menu and sidebar integration. It may actually take up more space, but it also forced me to re-evaluate what I thought was important and what I could simply leave out. (I now have 1 widget as opposed to 5.)
Anyway, that’s not the reason I’m writing. The reason for that is that over the weekend I found a bug, filed it, and it was closed in 22 hours!
When I moved over to the TwentyFifteen theme, I really liked the addition of the “Social Links” menu. Basically, the row of social media icons with links to my various profiles is a simple menu where you add a link, and based on that link, it will use the appropriate icon. You can find out more on the Social Links documentation page.
One of the things this would allow me to do is remove the “RSS Links” widget and simply have it as an icon for it with the rest of the social media icons (see the bottom of the screen shot). Having the RSS widget as a standalone takes up a lot of space (see the bottom of the screenshot), so I was happy to get rid of it.
However, as you can see in the screenshot, instead of an RSS icon, the leftmost icon is showing a WordPress icon instead.
Filing the bug
I didn’t know it was a bug, because it wasn’t listed on the TwentyFifteen announcement page, so it was originally filed as an enhancement.
I filed issue #31129 and I immediately got a response to let me know it was actually a bug.
Building the Community
Of course, it wasn’t that the first person to respond fixed my silly typo in my issue title, or that he refiled it for me in the proper place, but that I got a real response from a real person so quickly.
The fact that it was patched so quickly as well was a big bonus, but still a bonus.
If you read over the notes from the Community Building Practices Mozilla session that I attend late last year, there is prominent mention of needing to get at least the first response to a new contributor quickly. A first-timer is less likely to return the more time you leave an issue without a response.
I admit, this isn’t the first time I’ve filed an issue on WordPress, but I can also tell you that I have no issues open. Did my issue always get fixed? No. For various reasons (none of which I am unhappy with actually), we don’t always fix issues, and that’s fine.
The important part is that the issues are not lingering open for months or years. In some other places, I have issues open from more than 2 years ago (I’m certain I have older ones on sites I just can’t remember). In some cases, it’s a low priority issue and no one has gotten to it, okay fine. In other cases though, people just stopped responding.
Projects where people simply stopped responding? Well, I have stopped being involved with the project in any way, and I no longer post any issues. (I would still post about any major issues, but since I don’t use any of the tools from those projects anymore, I have nothing to report.)
Regardless of who did it, it’s clear that the patch for the WordPress issue I reported has been integrated and set for the next release.
The patch having been integrated for the 4.2 release means that I have already removed the RSS Links widget and will expect the icon to update itself to the appropriate icon in time.
At least, based on my experience, I trust that it will update itself. (Hopefully it does so…)
These aren’t new ideas, but I think sometimes it’s easy for people to forget. Yes, of course you need a good product that people will get behind, but a big part of why people go back to the same company, community, or project is the trust that you build in great part by being responsive.
Obviously, issues aren’t normally reported and fixed in less than 24 hours, but at least have a real person respond within 24 hours. Go back and look at issues that have not had a response in a long time. You can ask the reporter to even check whether it’s still an issue in the new version, but don’t just let it die. The more issues you simply let die, the more you destroy the possibility of someone ever coming back. This is common sense in the “customer service” model for companies, this should be common sense for open source projects as well.