On Submitting Bugs

bsoremsugar —  August 17, 2009 — 2 Comments

Wouldn’t it be nice if there was an RFC spec and protocol for human communication? Perhaps we’d have no more miscommunications and we’d be more effective.

Ok that’s pretty geeky wishful thinking, but if you’re submitting bugs to SugarCRM – one of the best ways to do it, is by following this protocol:

For example:

Description: describe the problem

Requirements: any dependent requirements to reproduce the bug. Please include platform information

Steps:
1. Foo
2. Bar
3. Baz

Expected Result:
Hello World

Actual Result:
Fubar’d

Take a look at this excellent real world example.

2 responses to On Submitting Bugs

  1. 

    Good input, I’ve been trying to implement the “Expected vs. Actual result” directive, but I must admit it hasn’t always been like that ;).

    One thing I feel I must point out is that your team can be a bit more better at communicating too: Whenever I submit a bug I cannot search for an existing one because the bug tool won’t allow searching in descriptions, this may be regarded as a feature request for searching in text fields in Sugar too ;). Then, the bug is filed as Duplicate which is reasonable, since every bug should only exist once. However, the original bug should be mentioned by the team so that the original reporter (me) can track its solution.

    Also, some of my bugs are “Out of Date” after being untouched for six months. Is this a standard policy? If the bug is fixed I think it should remain open, if its closed it should be set to closed/duplicate. Out of date is something I would use for a bug that occurs in an unsupported version or something like that.

  2. 

    Good input, I’ve been trying to implement the “Expected vs. Actual result” directive, but I must admit it hasn’t always been like that ;).

    One thing I feel I must point out is that your team can be a bit more better at communicating too: Whenever I submit a bug I cannot search for an existing one because the bug tool won’t allow searching in descriptions, this may be regarded as a feature request for searching in text fields in Sugar too ;). Then, the bug is filed as Duplicate which is reasonable, since every bug should only exist once. However, the original bug should be mentioned by the team so that the original reporter (me) can track its solution.

    Also, some of my bugs are “Out of Date” after being untouched for six months. Is this a standard policy? If the bug is fixed I think it should remain open, if its closed it should be set to closed/duplicate. Out of date is something I would use for a bug that occurs in an unsupported version or something like that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s