First Task Definition

Introduction

It’s become quite apparent that one of the most important factors in how much attendees enjoy our OSCTC events is the quality of the bugs/contributions they work on. It’s also apparent that our old system of scraping ‘bite size’ bugs from hundreds of projects and giving them a cursory look isn’t adequate for finding the right bugs.

This page is for phase I of the project - defining what makes a good bug. The questions below can help us with our definition. Feel free to add new questions, or to add to the definition below.

Some further thoughts

Relevant questions

Some questions that might help us create out definition:

• Set up:
  • How much work will the attendee have to do before they can begin working on the bug? Is there good documentation to help them set up their environment?
  • Is the location of the problem (in the code, documentation, etc.) given, or will the attendee have to find it on their own? If given, how precisely? (Do we know which file? Which function? Which line number?)
  • What systems does it use? For example, git vs subversion vs other version control systems?
• The bug itself:
  • What types of issues are we looking for? Bugs vs feature requests vs documentation vs design vs helping users on lists?
  • How long should it take to address?
• Social:
  • Will the attendee likely receive quick, friendly, useful feedback on their contribution from a maintainer or community member?
  • Does the project have a reasonably active mailing list or irc chatroom?
  • Is the task a good one to do in pairs or groups?

Quality Control

Some ideas we've had for quality control include:

• Come up with an amount of time a task can be on our system before it needs to be re-reviewed.
• Have OpenHatch volunteers review all tasks that are added to make sure they are appropriate.
• Have a feedback mechanisms for attendees at events wherein they can document problems they had with issues rather than giving up silently.