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.

Some further thoughts

Here are some things to think about as we draft our definition.

Relevant questions

Some questions that might help us create our 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?

Bad Task Experiences

What problems have folks run into in the past?

• Can't figure out which files or functions need to be modified for the fix to be made.
• The bug has already been fixed but the issue on the tracker was not updated to say so.
• The bug has become irrelevant since reported. (Mostly an issue with bugs over a year old.)
• Difficulty setting up development environment.

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.

Implementation Ideas

• Adding projects and bugs are separate inputs, and when inputting bugs you can select projects.

Definition

Project-level

• OH-Affiliated: yes/no
• Description:
  • Language(s):
  • Operating System:
  • Tools:
    • Code repository:
    • Version control system:
    • Communication tools: mailing lists, IRC, forums, or other
  • Activity: How many posts to mailing lists or issue trackers occur per week?
• Set up:
  • Dependencies:
    • What is the best way to label this information?
  • Estimated set-up time
    • What is the best way to estimate this information? (Seems like it would also vary based on who was setting up & their experience & OS and such)
  • Link to developer set up guide:

Bug-level

• Type:
  • Link to the ticket
  • Brief summary
  • List of skill tags
  • Does the ticket (or comments to the ticket) provide necessary and preferred information:
    • Steps to reproduce, including OS/version where relevant
    • Expected vs actual behavior
    • Localization of bug in the source code
  • Estimated difficulty/time to fix:
• Status:
  • Time since first reported:
  • Time since last update:
  • Has bug been deprecated?
  • Has bug been fixed? (Goes into archive)
• Notes
  • Reviewer (staff) notes
  • Attendee attempt notes

Should we have a separate input for feature requests?