RADAR OR GTFO
By Daniel Pasco more by daniel
A few nights ago, I got a little grumpy on Twitter. Xcode 4 has been very popular to snipe at, and some of the things I was seeing in my twitter stream were starting to feel a little tiresome and not particularly constructive.
Make no mistake: a lot of people - including people on my own team - have been seeing legitimate issues, and their productivity is being impacted. But what bothered me was the scarcity of tweets mentioning bug reports. Many people weren’t actually doing anything about it besides voicing their distress, which resulted in me posting this tweet:
This kicked off a heated debate about the efficacy of filing bugs against Apple’s products, so I decided to blog about a topic my friend Matt Drance (@drance on Twitter) had discussed at the last C4 conference.
Get to know your Apple Evangelist
I’d like to introduce you to a man named Michael Jurewitz. Michael works at Apple as the Developer Tools Evangelist. His job is to serve as a liaison between the people that build the tools we use to make our products and the people that use them.
Michael spends a lot of time advocating for developers. He’s accessible via twitter or email to field issues reported by developers and figure out who needs to see them. He’s been a big help to us in the past, but I have also personally been on the receiving end of this more times than I care to recall:
File a radar, or GTFO: Mike is going to need you to file a bug before he can even start to help you, because the first question he’s going to get from engineering is “what bug number is it?” He’s going to need some documented description of the issue in order to have a reasonable chance of dealing with it.
What is Radar?
(skip ahead if you already know this)
Radar is Apple’s bug tracking system. It covers a variety of issues, internal and external, and is the primary interface the development community has for reporting issues they’re seeing with Apple’s products and tools out in the wild.
If you’re a developer outside of Apple, you can access radar’s web interface at bugreport.apple.com.
Within Apple, employees have access to a Radar desktop application that they can use to access your issues. It’s pretty neat, and can automatically open hyperlinks (in email, for instance) of the form rdar://yourissuenumber.
What you are probably going to see
Most of the time, you’re probably going to get a response like this one:
12-Jul-2011 12:02 PM Apple Developer Bug Reporting Team : This bug has been closed as Duplicate. We are aware of and tracking this issue under the Bug ID listed above in the bug >State (Duplicate/XXXX). To check the status of the original bug report, please update your report directly and we will provide you with any available information.
Frequently, at least one other person will have reported the issue that you did. A lot of people get frustrated by this, because they think that their report has been summarily dismissed as reproduced effort, but really, they just don’t understand that filing duplicate bugs is a very good, important thing. Your duplicate counts, and here’s why.
Filing duplicates is critical to getting things fixed
Engineering organizations always have more work than they can handle, and routinely meet up with their managers to triage their pile of work and figure out what to take on next. The higher the number of reported cases of a particular issue, the easier it is to justify to the person you work for that the issue needs attention.
This is true of any software company. When you release a product, there will likely be one or two edge cases that people report, and you will likely try to figure those out as soon as time permits. But when hundreds of people are reporting the same issue, it becomes clear that the situation is rampant, and requires immediate attention. Apple is no different from any of the rest of us in this respect.
Filing a duplicate bug is your way of up-voting, or bumping, a reported issue. The more duplicates that show up for a specific issue, the higher priority that issue becomes.
On the other hand, there are few things sadder than exchanges like this one between the illustrious Matt Gemmell and Michael:
An issue with only one open ticket is pretty much going to be statistically lost in the noise and is likely to be overlooked unless more people start reporting it.
But even if there are other tickets opened on the same issue, maybe everyone else’s reports on the issue suck. Your post may provide engineering with some crucial information they need to triangulate on the issue and fix it.
Radars don’t have to be expensive to file
To start, getting the issue captured is probably more important than providing sample code that demonstrates the issue, particularly if there are lot of duplicates for the issue you’re reporting.
I have been berated many, many times for not filing a radar on something before asking for help. As a reporter, I feel like it’s my job to provide a test project that clearly shows the problem occurring, and I usually feel like I’m just going to hear “We can’t do anything until you show us how to reproduce it.” Since I don’t have some way of demonstrating the issue (and often can’t easily spare the time to put one together), I end up dragging my feet on actually getting the problem captured in the first place. That doesn’t help anybody.
And, as a matter of fact, I usually do get a response asking me to provide steps to reproduce the issue, or some sample code along with the ticket. But at least once the issue is captured we have a common point of reference we can talk about, and honestly, the folks at Apple can be pretty earnest about wanting to see how serious the issue is. Getting the ticket opened in the first place is a very good way to get a dialog going, find out that its something they need to see to handle, and THEN you can opt to spend your time isolating it a sample app for them.
That said, you get some pretty good extra credit for supplying the sample code up-front, so if you’ve got the time, do it. My friend Danilo Campos and I also like to use sample apps as a way of making sure that the problem is actually a bug in Apple’s code, and not just us shooting ourselves in the foot with a bug of our own. So it doesn’t hurt to be proactive about it if you can.
If you see an issue, get the word out
File your radar, then go to Open Radar and post the same bug there as well (don’t do this for beta products under NDA!). Then tweet the open radar link so that other people are aware of the issue as well. Hopefully that will spur on other people experiencing the same problem to file a report of their own.
If you haven’t heard anything back within a few days, ping @jury, @behrens, or someone like @ctp, and let them know about the issue. MAKE SURE YOU INCLUDE THE rdar:// link, because that’s the first thing they’re going to ask you for if you don’t provide it.
These are good people, and they care about this stuff. Help them help us.
If you have issues with the radar system itself, don’t let that keep you from using it. File radars on radar, and then tell other people about what you’d like to see changed, too.
Finally, here is a list of issues our team captured and sent into Apple today. Please file a duplicate if you are dealing with any of these problems yourself.
*Duplicates of the first bootstrap issue opened by other members of our team struggling with the same problem.