Technology Weblogging

WordPress and bug databases and communication

Recovered from the Wayback Machine.

The folks behind WordPress have made a step in the right direction by first of all, not deprecating old functions without going through a formal deprecation process. This is to ensure that people have time for a release or two to modify a now deprecated function or global variable before it is pulled from the application.

They’ve also just started a bug database, and this could be good – if they understand that a bug system is a two-way communication process. It’s not always about code.

entered a bug in the database yesterday about the fact that if you turn off magic quotes in your .htaccess file, but you try and edit a comment and save it, it causes the SQL to crash. The reason for this is that the text of the comment isn’t ‘escaped’ – slashes put in front of quotes contained in the text to tell the database to treat these are characters, not the end of the database string.

Well, the response was to point to a change record in CVS in the newest releases of the code an d say, ‘Does this fix it?’

Well, how the hell do I know? I’m using 1.2. What if I can’t read code? Wouldn’t an English description acknowledging my problem and the solution have been better? With a little note about when it will be released? Such as, “This fix will be released in the 1.2.1 bug fix release”.

Bluntly, the WordPress development crew is not happy with me because I’ve been pushing them pretty hard for the last month. What I’ve been saying is that software is only 50% code – the rest is documentation and infrastructure, quality testing, and communication. Particularly communication.

Oh, you don’t need these things if your code is used by hackers or a small group of friends. But if you want your application to be used by strangers who don’t code – you can’t force them into learning code to communicate, or having to beg pretty please in order not to piss off the development people.

I’ve gotten a lot of flack for my criticisms of past weblogging tools. I stand by these criticisms, every single one of them. I’m not, now, going to play ‘touch not the programmer’ just because the source code I’m now using is open source. If anything, I want the open source solution to work, so will be harder, not easier, on the team behind the product. Is this unfair? What’s fair? Not being critical because this just isn’t done in weblogging?

Unfortunately, the team doesn’t see that I’m attempting to help them succeed over time–by realizing that an application is more than just code. My own frustrations aren’t helping, and have led me to become increasingly confrontational. My bad.

What I’ve been trying to say is that a successful application is demonstrated by the trust of those who use your product, and based on understanding what the users are saying and making an attempt to communicate in their language. It’s slowing down development if it means that the end product is more stable or secure. It’s releasing bug fixes, and developing a plan for future development and communicating it. Most of all, it’s realizing that people can’t be grateful forever. Eventually, the product will have to stand on its own, not on gratitude.

(Six Apart is learning that one rather painfully now.)

In short: a successful application is only 50% code.

But I’m also not going to trade my ‘kicking the baby squirrels’ tag for one of ‘kicking the open source baby bunnies’, either. If I’m not helping and all I’m doing is making people pissed, then time to stop what I’m doing.

Disappointing, though.


I’m glad I posted this and had conversations offline and on. It helped me refine, at least for myself, why I’m pushing at the WordPress group so much.

Much of it goes back to the concept of the Coders Only Club, and having to put code down at the door in order to ‘purchase’ the right to be heard. I want this open source application to belong , as much or more, to the non-geeks as it does to the geeks. I think we could have a lot of fun together.

However, the project is young, the developers are trying, and they are most likely getting tired of ducking from me, and my beating about their heads with my ‘help’.

General agreement is that I was too harsh on the WordPress developers. Guilty as charged. It’s their project – up to them how they manage it.

As for myself, I’m just going to maintain my own code at this point, and doing my own enhancements.

Sigh of relief for the WordPress team and their so-loyal fans. One less pain in the butt to worry about.

Print Friendly, PDF & Email