Denderello's Blog
What I have learned about tickets at symfony BugHuntDay
Now that I'm back from symfony BugHuntDay I have some time to talk about the things I've learned during this event. Although I just fixed one single bug (shame on me!) there were several things that I discovered and learned while fixing bugs and talking to people.
Thanks!
First of all thanks to intracto who organized the symfony BugHuntDay. You guys did a very good job! And also many thanks to the core teams memebers as well as the attendees who joined us in Herentals or via IRC. You all had the chance to spend your free time with something else and decided to use it for some bug hunting.
As Stefan already wrote up a report about the BugHuntDay I will focus on some things I've learned or that made me think about alternatives to the current situation.
Scanning tickets is time consuming
One of the main reasons why I just fixed one single bug (shame on me again!) is the fact that just scanning the tickets is very time consuming. You read the title, open it, read the description and try to think: "What does the creator wanted to show me?". Then you try to re-create the bug in your sandbox system to find out you can't. Mainly there are two reasons for this:
- The bug is already fixed by something (maybe an update or a commit) during you picked it up
- You don't have enough information to re-create the "environment" in which the bug shows up
There might be other reasons but these two were the main reasons I faced during the BugHuntDay.
However if you face the problem that you can't reproduce the bug you already have spent time for this. If you found that the bug was already fixed your lucky. If not... well, you can imagine.
Just stating your opinion in a ticket is useless
Before talking about this I want to say that I don't want to blame the creators of the ticket I will talk about. In the past I created bad bug reports, too. But the BugHuntDay gave me the opportunity to see the other side of the bug report lifecycle.
So, sometimes you face a situation that seems like a bug, maybe annoys you, or you just don't know what's happening (but you know something is definitely wrong). The worst thing you could do is to create a ticket and just state your opinion about your situation. This won't help you nor the bug report reviewer.
If you think that you might need some help with your situation just the dev or users mailing list, the forum, or the IRC channel. If you think you found a bug, try to provide a patch for it. And don't forget that even the symfony documentation is patchable via svn!
Provide as much needed information as possible
Some bugs could be reproduced much easier if they would provide more information about how to reproduce it. A good rule of thumb for this is the following:
Try to provide all the information needed to reproduce the bug as if you were someone of the ticket reviewers.
Sounds stupid simple and obvious? Although it is, some tickets suffer from this problem.
Why did I not name any tickets?
I first thought about adding tickets as examples. First I think this would be unfair because I think that I'm not in the situation to blame others directly (because I'm not perfect, too). Secondly I think this is a good chance for you to take a look at the tickets yourself and try to think about what I wrote. Maybe you can get an idea about what I mean.
This work by Dennis Benkert is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
© 2009 by Dennis Benkert - legal information
Hi Dennis,
I am glad you noticed what I wanted to show :-) I think the main reason is the second.
Almost everybody of the core team knows most of the tickets. If we fix something we will almost always know that there is a related ticket and close it.
There are a few hundred tickets open, and most of them are either invalid, or not fixable by design. There are only a few that are real fixable bugs. And as you said, it takes about 4 hours to work on such a ticket, which is why we need help :-)
Awaiting you patches :-)
Adding tickets to trac is really boring.
I added two and, since I'm a programmer too, I tried to be as descriptive as I could, providing code snippets and solutions (where possible).
The worst things I saw are:
- the textbox where user write bug body is really small; I used FireBug to patch the css and make it higher to at last 500px ;)
- Wiki syntax is the most unnatural way to insert text and code: most of the bugs are badly commented, maybe because a developer doesn't want to spend most of its time to write in such innatural language
- cut&paste simply does not work, because line feeds must be something like [[br]]... what? your pasted text will simply render unformatted.
- trac is really, really slow: it takes longer to search for an already open ticket than adding a new one... which is long too!
This IMHO, I know that there should be someone who likes Wiki syntax and trac too.