Lounge

[adapted from a post by Brent Simmons. Might be useful reading in this beta testing--bug reporting time ]

Then of course there are bugs to fix, schedules to meet, tests to run, docs to update, user interfaces to design, lots and lots of things. Most of your time is spent just sitting in a chair, coding, because thats the only way things get done. (Oh, and then theres email. And writing blog posts. And so on.)

Okay, to put it in a nutshellthe input is like a firehose, and theres a ton of work to do, and both things are always true. So what do *you* do, the average Moodle user to manipulate me, the average Moodle developer, to do the things you want done. Here are some things that don't work and some things that do work .

Manipulative Things That Don't Work Anymore

The just one thing maneuver

This is the one where if I did just one thing then youd _____ (insert something good). This doesnt work because, well, I know you really want more than one thingor you will, anyway. And of course there are lots of people who want just one thingbut its a different just one thing for each person.

The I consider the lack of feature x a bug ploy

When youd like to see a feature, you cant make it happen faster by telling me you consider the lack of a feature a bug. Its clever, yes, but not the nth time. I really do classify stuff by bugs and features, and a feature really is a feature. (Yes, some features are obvious to-dos, but theyre still features.)

The surely it must be easy for a developer like you scheme

This one almost works, but Ive grown immune. (Slowly, over many years.) Very few things are easy. Quite often the coding is easythe actual coding is one of the easier parts of the job. Its the user interface design and software architecture thats harder. Many of the easy requests arent easy at all. (Some of them require advanced artificial intelligenceand raw computing horsepowernot seen outside the wreckage of the Roswell craft. Easy often means easy to a humanand, much as I love my Mac, no amount of ardor will give it human intuition.)

The maybe you should put it to a vote finagle

Ive learned not to take that as an insult. Its not meant that way. I used to think the person was besmirching my ability to determine whats best for the product based on what I think and the feedback I get. Ive learned that lots of software developers do in fact take votes from users, and thats coolits just that I get so much feedback already that setting up voting means more work with not much added benefit. I already know what people are asking for the most.

Being mean

Okay, this one is hugely rareMoodle users being the way they are. (Super-nice folks!) But now and again someone does come across as less than polite. It doesnt work. I take the bug or request seriously, but Im not going to give something a higher priority just because the person was rude. (Better to butter me up. Dont worry about going too faryou cant. ;)

Manipulative Things That Always Work

Now Ill tell you straight up the secret formula--how to manipulate me. Save me time. Time is so precious, its everything.

Saving time with bug reports

Consider bug reports. Whats the hardest thing about a bug report? Almost never is it actually fixing the bug thats hard. (Sometimes, but not usually.) The hard part is reproducing the bugthat is, understanding whats going on and being able to make it happen at will.

Once I understand a bug and can make it happen, I can fix it.

Good bug reports contain as much detail as possible and are specific. Generalizing and leaping to conclusions in a bug report is not helpful and is usually incorrect.

For instance, Ive had bug reports like this: The RSS feed doesnt support UTF-8.

Well, of course it does. I have no idea what the person is seeing and why he reports this bug. I end up having to play 20 questions, which is a waste of my time and his.

In the end we get it narrowed down to the actual bugwhich (for instance) is that the descriptions for a specific feed show as garbage characters rather than the expected characters. Imagine how it would have helped to know the URL of the feed and the specific problem in the first place!

The best bug reports follow this form:

1. What I did. (With as much specific detail as possible. Including URLs of feeds or URLs of weblogs when appropriate!)

2. What I expected to have happen. (Again, with detail.)

3. What actually happened. (With detail.)

Things like screen shots can really help, tooas long as you also use text to explain whats wrong.

(Why is step #2 important? Because some bugs are expectation bugs. That is, its working fine, but you expected something else to happen. Expectation bugs sometimes point to a user interface design or documentation bug. But not always.)

One other thing that can be super helpful is sending crash logs or error reports if something goes wrong. This can be done by turning on "debug" in your Admin configuration page. Debug is useful because it lets me know what the software was actually doing. No guessworkfacts, which saves me tons of time.

Saving time with feature requests

Most people think theyre like most other people most of the time.

And theyre rightexcept when it comes to software.

The first thing to know when writing feature requests is that, despite what your intuition tells you, despite your experiences in the rest of your life, you are not the representative user. You are specifically you, an individual, with your own ideas and needs and wants. (Its a Good Thing! Dont be scared! Im a doctor, and Im here to help!)

So... lets imagine a feature: Tuesday Whipper-Snapping.

It may seem obvious that Tuesday Whipper-Snapping is a slam-dunk. Surely its easy to do, surely every user wants Tuesday Whipper-Snapping, surely that would take the software to the next levelsurely its a bug, really, that Tuesday Whipper-Snapping isnt already in there.

Say I agree that Tuesday Whipper-Snapping is a good idea. I add it to the list: its now the 347th good idea.

The trick, though, is getting me to think its a super good idea.

The trick is not, as you might expect, to convince me that its something lots of people would want. The trick is to tell me how you would use it, how it would benefit you, how it solves a problem that you have.

Forget about other peoplelet me do any extrapolating. (Its my job.) Instead, just tell me a great story about how this feature would be cool for you. (It goes without saying, by the way, that its the just one thing you have to have. ;)

Also remember that, lots of times, software developers pay more attention to the problem being solved than to the exact feature being requested.

Think of ExposéI doubt the folks at Apple had feature requests that read like this, Please make it so that I hit a hot key and all my windows fly around and make it so I can mouse-over them and pick the one I want. Instead, they probably had feature requests like this: Please add a global window menu to the Dock so I can more easily pick a window from any app. They probably didn't listen to that, but caught the problem, "I have so many windows open, piled up on top of each other, that I can't find the right one!".

So they listened to the problem and came up with another solution, one that probably nobody had requested specifically, but that is really cool.

Sometimes that happens, sometimes not: Im just saying that telling a good story is important, because my goal is really to solve problem, not just implement specific requests.

If you tell me good, specific stories about you and the software and the problem you want to solve, then Ill know why the feature is important, and that makes it more likely Ill get to it sooner.