Lice!

A Vow to Create Tickets

I’ve had some open source projects before, actually quite some, but Project FiFo is by far the most successful one. And aside from the technical perspective I’ve learned a tremendous amount of new things already, one of which I want so share since. It sounds simple but I never looked at it this way before: Tickets.

The project has caught on momentum so fast that at ‘rush hours’ people come with questions, bug reports and feature requests at rate that it’s they pile up faster then we can help or answer, the channel and community already does a great job ‘filtering’ out easy to answer topics but enough are complicated to a point where a developer has to look at them.

I’ve been on both sides of the fence, and I had the honest believe that it’s easier for developers if you just pop by the IRC channel and ask/report a issue. And that is not entirely wrong often a quick ‘hey I’ve problem X/Y’ is enough to solve a situation others had before that can be resoved with a few words.

What I did not realise is how crucial it is to open tickets for anything that can’t be resolved directly. The reason for this is simple, usually there are N users for 1 developer and for each user it’s easy to keep their topic in mind and present it can become very had very fast for a developer with three users to listen to.

But I don’t want to wander of ranting, instead I’ll try to explain why a ticket really helps me to get stuff done.

Organisation

Tickets make it very easy to keep track of them, assign them to people (given you’re not solving them yourself) and add followup data. Tickets can be prioritised and categorised, this makes it very easy to group related items or even look up known issues.

The more tickets there are and the more people working on them the more important this gets, handling six tickets gets way easier then handling six email conversations or unthreading six conversations from a IRC channel.

Information

One of the great things about tickets is that they can contain additional information, it’s absolutely helpful to look at a issue that already has some information attached that goes further then three lines and a “it isn’t working”.

To make this better it is also possible to add files and logs which can contain much more information to a ticket and those can be ‘handed around’ between different people looking at the issue without the need to send mails.

Followup

Tickets are a two way street, once a ticket is logged the reporter can see it’s progress without having to ask - or at least can ask if it is not handled for a long period. Also it is easier to say ‘hey what is the status if ticket #42’ where all the information is provided already instead of ‘hey how about that bug that happened when …’ and have to explain it all over again.

Deduplication

Once a ticket is logged it’s visible for everyone, there is no reason to go around and ask ‘hey do you know the bug …’ or ‘what are your thoughts about feature …’ and perhaps even get a wrong answer since you’re talking to more then one person. This makes everyones live easier.

Comments