The Blog

Writing bug reports

by Tim Wood on May 15, 2007

Now that OmniFocus is sticking its toes out the door, this seems like a good time to remind everyone about best practices on reporting problems.  Crash reports are especially important and should receive extra care.

  • Please report every single crash you hit, even if you don't know how to reproduce it yet.  Include any details of what you were doing leading up to the crash.  We can then correlate reports from different users to narrow down the cause, even if no one person can reliably reproduce the problem.

  • If you are comfortable doing so, include your document as a starting point (for OmniFocus, this is in ~/Library/Application Support/OmniFocus).  If you have qualms about sending your data, skipping this is OK.  Another option is to export your file to a backup and then trim down that copy to include only the portions necessary to reproduce the problem.

  • List the exact steps to reproduce the problem, starting from the file you included or from an empty document.  It is hard to be too specific: for example, you might be tempted to say “I deleted the second task of the project 'Foo'”, but this doesn't make it clear whether you used the delete key, a main menu item, a context menu, invoked an AppleScript, or picked up the task and dragged it to the trash.  In some cases, the distinction matters.  When in doubt, describe the physical actions you used (“press key X”, “clicked button Y”).

  • If the proper behavior isn't obvious (“don't crash”), tell us what you expected to happen.  Maybe you have a perspective on a design question we haven't considered or that we should reconsider.

With crash reports in particular, it is important to include reproducible steps.  Sometimes this isn't possible, and that's fine—please report the crash anyway with whatever details you have.  With a large enough pool of people, someone will be able to figure out how to reproduce it.

Crash reports are CC'd directly to the entire OmniFocus engineering team.  If you include reproducible steps, we'll typically stop whatever else we're working to fix it immediately.

 

Comments

I'd be testing and reporting bugs like a very speedy bug-reporting thing, if only I hadn't found the mailing list signup in April.  :-)

Brian

05.15.07 6:43 AM

[...] Und die OmniGroup gibt Tipps für den Bugreport der Betatester, die übrigens im 100er-Pack informiert werden. [...]

GTD: OmniFocus beta die 2. « Die Kritiker

05.15.07 7:48 AM

Why don't you just create a log of all actions a user does just for this beta program?

You would get very accurate bug reports that way.

There could be an option in preferences to disable this feature for paranoid people.

Sebastjan

05.15.07 8:10 AM

You may want to check out this as a crash reporting tool:

http://smartcrashreports.com/


It's free and ties in with macs crash reporting.

SpiralOcean

05.15.07 11:24 AM

Not to be dense, but where should we send these reports?

TjL

05.15.07 11:25 AM

Send bug reports to: .(JavaScript must be enabled to view this email address)

michelle

05.15.07 11:33 AM
Team Member

spiralocean: Is there something specific about smartcrashreports that makes it preferable to Omni's CrashCatcher?

Lizard

05.15.07 12:05 PM

TJL said “Not to be dense, but where should we send these reports?”


In OmniFocus there is a “Send Feedback…” item in the “Help” menu. Using this creates an email with the version and build number in the subject line ready for you to send to OmniGroup.

coconino

05.15.07 5:59 PM

[...] May 17th, 2007 · No Comments I beta test a lot of software and services. Most just assume that people know how to write up a bug or crash report. People don’t. Yesterday, the OmniGroup’s blog (The OmniMouth), posted exact directions, in light of the first beta build of OmniFocus, a detailed how-to. [...]

What I love about the OmniGroup « Setting Co

05.17.07 2:45 PM

[...] I beta test a lot of software and services. Most just assume that people know how to write up a bug or crash report. People don’t. Yesterday, the OmniGroup’s blog (The OmniMouth), posted exact directions, in light of the first beta build of OmniFocus, a detailed how-to. [...]

My Get Things Done List » Blog Archive &raqu

05.17.07 3:03 PM

I signed up March 5… anyone know how close I am to getting a chance to have a peek?

Geoff

05.19.07 10:26 PM

You really should if your not all ready, be aware of Joyent. Their online groupware takes OO imports, the new addition of “List” work great with OmniOutliner.

I can't help but think what it could do with OmniFocus.

MWCDan

05.22.07 10:22 AM

after all the excitement last week when the first beta was announced, things seem to have become awfully quiet. isubscribed to the mailing list on the 3rd may, so i don't suppose i'll be getting to see the goodies very soon ;(  ... as a long-time and very happy user of omnioutliner pro, i'm very excited about omnifocus, i've recently been using some rival software (with a big yellow triangle and exclamation mark).  THAT does the job very well- possibly less feature rich than OmniFocus perhaps, but it's pretty well made - esp. for something free. i'd really love the chance to make a thorough comparison.  i wait patiently

ken

05.22.07 7:08 PM

OH MY   I an so excited about omni Focus, I wish i could play with beta… I completely depend on kGTD now… :)

Thank you omni group

dave

dave

05.27.07 1:58 AM

Hmm. 2 Weeks, and still I haven't seen an email. I was really looking forward to seeing the beta - when can we have a look ?

Andy

05.29.07 7:55 PM
Commenting is not available in this channel entry.