Open Source Comes to Campus/Newcomer Tasks/Issue Tracker Cleaning: Difference between revisions

From OpenHatch wiki
Content added Content deleted
No edit summary
No edit summary
Line 19: Line 19:
* There was enough information for you to attempt to reproduce the bug, and you reproduced it.
* There was enough information for you to attempt to reproduce the bug, and you reproduced it.
* There was enough information for you to attempt to reproduce the bug, and but you did not reproduce it.
* There was enough information for you to attempt to reproduce the bug, and but you did not reproduce it.

In each of these cases, you'll want to leave a comment on the issue.

==== Not Enough Information ====

An ideal bug report has a lot of information. That includes:

* Steps to take to reproduce the problem, including any input (this can be files, text, or instructions such as "click the leftmost button"
* What they expected to happen
* What actually happened, including the text of any unexpected output such as error messages
* Software and operating system versions

If you are having trouble carrying out the steps to reproduce a bug, you should ask a mentor or member of the community whether they can supply the missing information. For instance, perhaps the bug reporter references a part of the project you can't find. It may be, though, that the reporter did not provide enough information for anyone to attempt to reproduce the bug.

In this case, you can help everyone out by identifying the missing information and leaving a comment asking the reporter to provide that information. For instance, you might write:

<blockquote>I'm trying to reproduce this bug, but it's not clear to me what you did leading up to the problem. Which input type seems to cause the problem?</blockquote>

or

<blockquote>Thanks for reporting this bug! Can you tell us which version of the project you found the bug in, and which operating system and version number you're using?</blockquote>

Revision as of 20:14, 29 July 2014

Overview

Sometimes communities need help handling all the issues that have been reported. They need to know whether bugs can be reproduced and whether patches/pull requests work as intended. You can help them out by a) reproducing bugs and b) reviewing patches! Along the way, you'll learn a lot about the project.

There are two main types of task you can choose to work on: reproducing bugs, and reviewing patches. Find out how to do each of these tasks below.

Before you begin, you will need to pick a project to contribute to. To do this, try our Finding a Project activity.

Reproducing Bugs

To find bugs to reproduce, look through the issue tracker. You may want to filter the issues you see so that you're only looking for "new", "unconfirmed" or "open" issues. )Some projects use different terminology, so you may want to ask a mentor to help you figure out what to filter for.) You're looking for issues where a problem has been reported and there are either no comments, or comments requesting that someone verify the bug.

Once you've found a bug report, you'll want to try to reproduce it. You will find yourself in one of three scenarios:

  • There was not enough information in the original report for you to attempt to reproduce it.
  • There was enough information for you to attempt to reproduce the bug, and you reproduced it.
  • There was enough information for you to attempt to reproduce the bug, and but you did not reproduce it.

In each of these cases, you'll want to leave a comment on the issue.

Not Enough Information

An ideal bug report has a lot of information. That includes:

  • Steps to take to reproduce the problem, including any input (this can be files, text, or instructions such as "click the leftmost button"
  • What they expected to happen
  • What actually happened, including the text of any unexpected output such as error messages
  • Software and operating system versions

If you are having trouble carrying out the steps to reproduce a bug, you should ask a mentor or member of the community whether they can supply the missing information. For instance, perhaps the bug reporter references a part of the project you can't find. It may be, though, that the reporter did not provide enough information for anyone to attempt to reproduce the bug.

In this case, you can help everyone out by identifying the missing information and leaving a comment asking the reporter to provide that information. For instance, you might write:

I'm trying to reproduce this bug, but it's not clear to me what you did leading up to the problem. Which input type seems to cause the problem?

or

Thanks for reporting this bug! Can you tell us which version of the project you found the bug in, and which operating system and version number you're using?