1 of 18

Bug Reports

and Bug Triage

Dave Methvin

2 of 18

This is How I Got Started

in Open Source Development

3 of 18

4 of 18

5 of 18

The Most Common "Bug Report"

IT DOESN'T WORK!

6 of 18

7 of 18

WHAT DOES THAT MEAN?

8 of 18

9 of 18

What is Needed to Fix a Bug

  1. A clear explanation of the problem
  2. A test case that shows the problem, if it's in code
    • jsbin.com
    • jsfiddle.net
  3. An agreement there is a bug
  4. A patch to fix the bug

10 of 18

Creating Good Test Cases

  • Don't just link to your web site or project
    • It's hard to understand what the problem is on a complete site
    • The "test case" may disappear as you continue to work on it
    • There's too much "other stuff" that might be causing this
  • Use the minimum amount of code, HTML, CSS needed to reproduce the problem
  • Be sure it's a bug
    • Search on StackOverflow to see if others have encountered it
    • Ask some other devs that you know
    • GOOGLE

11 of 18

Triaging a Bug

Project maintainers should always appreciate that someone took the time to report a problem instead of being a Scumbag Steve.

Whether the report really represents a code bug or not, it often represents some issue with the way users interact with the code.

Being human, sometimes project maintainers get frustrated when they have to handle the same problem over and over. And sometimes, they're just jerks.

12 of 18

Things That Can Happen to a Bug Report

13 of 18

Reviewed by the Project Team

14 of 18

Outcome: This Is Not a Bug Report

  • Doesn't describe the problem
  • Doesn't have a test case
  • Is really asking for technical support or programming help
  • Is this a problem with the project's "bug reporting funnel"? Is there a better way to direct those people?

15 of 18

Outcome: This Is Not a Bug

  • That's the way it's really supposed to work
    • Is documentation clear enough? How can it be better?
  • If it's a bug, it's not our bug
    • e.g. JavaScript arrays work a certain way
    • e.g. 0.1 + 0.2 isn't exactly 0.3

16 of 18

Outcome: That Can't be Changed

New users sometimes come up with ideas for "better ways" to do something, without understanding that their suggestion would break all the code written by others. Even if it's a good suggestion, it can't be changed without breaking everyone else's code.

17 of 18

Outcome: You Are Right, This is a Bug!

It should be fixable by doing this

OR

It sure would be good if someone knew how to fix it

18 of 18

Examples

http://bugs.jquery.com/ticket/9904 - These people are all contributing to open source, even years later, and all were participating this weekend.

https://github.com/jquery/jquery/issues/2649 - A good example here, but this is actually a misunderstanding of JavaScript arrays and not a jQuery bug.

https://github.com/jquery/jquery-migrate/issues/75 - This was really a technical support request, the reporter was in the wrong place.

https://github.com/jquery/jquery-migrate/issues/53 - Don't be cranky and then realize minutes later that it was really your mistake!

https://github.com/lodash/lodash/issues/1510 - The project team accepts a feature suggestion and asks for a code contribution to implement it.