When it comes to WordPress development, there typically tends to be two camps (with a third that’s on the rise):

  1. There are theme developers
  2. There are plugin developers
  3. Then there is the growing field of application developers

Personally, I’m a fan of building plugins. Obviously, it’s not because I have anything against building themes, but I’m a programmer – not a designer – by nature, so I add to the WordPress experience through functionality rather than functionality and design.

In fact, I think if I had to design, it’d probably take away from the experience :).

But plugins are software and there are problems that have existed as long as software has existed. In fact, entire markets have been created around said problem: filing bug reports.

I’m not here to provide the ultimate solution for how to provide a WordPress plugin bug report – if that existed, it would have been solved long before today; however, I do want to share a couple of things that I’ve noticed.

The State of Reporting Bugs

Most developers usually do two things when they release a plugin for WordPress:

  • The publish a post or a project page about their plugin
  • They release the plugin to a repository – either to the official WordPress plugin repository, or to a repository on a site like GitHub

We do this because it allows us to simultaneously announce the project, share a little bit about our experience in building the project, and to publish it into an area that will result in high visibility.

But it’s not without its challenges.

Fragmentation: (Or “On Pages and Repositories”)

Fragmentation

Fragmentation exists between users and developers.

First, as soon as we publish our plugins in multiple places, we’re opening multiple channels of communication. This means that we’re responsible for checking our comment feed as well as the repositories forum (or issues, if using another system) for when users report their issues.

This is a challenging problem because we shouldn’t place the burden on the user for where to post their issues. I argue that the repository is the place to do it, but I can’t penalize the people that leave their feedback on the project’s page or in my inbox.

Furthermore, I don’t want to stop publishing content about my projects as it allows me a bit more freedom to talk about the technical aspects of building the project.

It’s not as simple as disabling comments on those posts, either. After all, other developers and/or designers may chime in with feedback that’s valuable to improving the plugin, my future work, or even my process. I don’t want to miss out on these comments.

On top of all of that, the various problems and resolutions now exist throughout multiple places on the web.

Expectation of Delivery

Delivery

There’s a level of expectation between a request or a report and its resolution.

The second challenge that comes with managing plugins is the expectation of delivery that some – certainly not all – users have. I’m deliberate in distinguishing between users and customers:

  • Users are people who have downloaded your project, use it, and may or may not offer any type of feedback
  • Customers are people who have downloaded your project, and either paid and/or made a donation

When it comes to releasing a free plugin, there are several obligations that I believe the developer has:

  • The plugin should work with whatever version(s) of WordPress it claims to support
  • The developer should be responsive to both users and customers alike but is not obligated to build custom features for users

Unfortunately, there’s a type of user that expects a plugin to be updated after a feature request has been made and should be done so as soon as possible. Unless there is a significant bug in the plugin, then I disagree.

Just because a project has been released for free does not mean that the developer is bound to updating releases on a timely schedule. Unless the plugin in question is helping to pay rent or the mortgage, then it’s development is automatically de-prioritized.

Managing Responses

Managing Responses

Not everything is a disaster nor does it require that type of response.

Finally, if you manage a plugin that has even a few hundred downloads, then you’ve likely experienced the problem of how to best manage the feedback around your project.

Feedback can come via email, tweets, comments, forum posts, or who knows however else. In fact, one of my business partners has even had phone calls(!) about a product.

Clearly, I’m all for enhancing the user’s experience and for providing a service to the user, but I also expect a reasonable level of respect and communication in return.

But I try to believe the best: The problem is that the user doesn’t know how to be respectful, it’s that they don’t know how to best communicate with the developer because we’ve provided them with too many channels.

Of course, developers have different preferences on how they manage communication; however, one thing is for certain: There are things that each user or customer can provide when filing a WordPress plugin bug report.

Filing a WordPress Plugin Bug Report

In short, you should provide as much information as possible.

Here are a few things to help get you started:

  • What version of WordPress are you using?
  • What theme are you using?
  • What version of my plugin are you using?
  • Have you tried deactivating all plugins save for the one that isn’t working and see if that resolves the problem?
  • If so, can you please provide a link to your site?
  • Please provide the clearest steps for reproducing the bugs as possible
  • Please do not provide me the login credentials to your site as there are legal implications around this.

These are the questions that I find myself asking both users and customers 99% of the time.

Getting answers to these questions can help quickly pinpoint the bug and then get the user the quality of support they deserve (and that we – as developers – want to provide!).