Curated First Tasks: Difference between revisions

From OpenHatch wiki
Content added Content deleted
imported>Paulproteus
imported>Paulproteus
(Read my lips: no new paragraphs)
Line 32: Line 32:
===List of projects we are working with ===
===List of projects we are working with ===


Since MediaWiki doesn't have a revision-trackable spreadsheet that we know of, we're tracking prospective projects that we're reaching out to here:
Since MediaWiki doesn't have a revision-trackable spreadsheet that we know of, we're tracking prospective projects that we're reaching out to here: [https://docs.google.com/spreadsheet/ccc?key=0AoHP1ey91UqPdC1EUFV4aXBETmY3bFBzTFhpdG1ISEE Spreadsheet of prospective projects]

[https://docs.google.com/spreadsheet/ccc?key=0AoHP1ey91UqPdC1EUFV4aXBETmY3bFBzTFhpdG1ISEE Spreadsheet of prospective projects]


=== What makes for a good bug? ===
=== What makes for a good bug? ===

Revision as of 22:12, 8 January 2013

Our Motivation

Our “Open Source Comes to Campus” events rely heavily on students attempting to fix real bugs in active open source projects. As such, it's important for us to identify a large number of good "bite-size" bugs that students can work on. Past experience has taught us that an appropriate list of bugs can not be generated at the last minute, but rather needs to be curated over the weeks leading up to an event.

The bitesize bugs listed in a project's bug tracker are a good start, but we have found it's helpful to manually curate the tasks and often to provide hints to the bug's solution in the bug tracker.

We are excited to make connections with open source projects that are looking to welcome new contributors into their communities. We believe that this process will benefit everyone involved.

Process

Our intention is to create a list of open source projects which we will work with to collect good beginner bugs for our events. To do that, we will:

  • Get in touch with the development community of the project to ask if they are interested
  • With the project's enthusiastic permission, create an Open Hatch account in that project's bug tracker which can claim and/or be assigned bite sized bugs
  • assign ourselves bugs, for which we will provide a release-by date (never longer than four months, but usually not shorter than two weeks, from assignment)

We are happy to work with project communities to make sure we are not taking too many bugs or in any way impeding development. We also wish to stress that, for any individual bugs, members of the community would be welcome to say, "Actually, I would like to claim this one" or "If you can't have this done by X date, please release it now."

Bug List

These are hand-picked bugs we intend to use at Open Source Comes to Campus events. If this goes well, we will work on merging the current automatic import process of the volunteer opportunity finder with this manually-curated list.


  1. Brief Description
    1. Link to bug tracker
    2. Release By:
    3. Project: Link; OS:  ; Installation Time: ; TTNR:
    4. Notes

List of projects we are working with

Since MediaWiki doesn't have a revision-trackable spreadsheet that we know of, we're tracking prospective projects that we're reaching out to here: Spreadsheet of prospective projects

What makes for a good bug?

Keep these things in mind when choosing tasks:

  • The typical attendee has 1-2 semesters of programming background (naturally this depends on the year they are, and the program they are in, and their programming experiences outside of college).
  • We aim that someone experienced with the code should be able to fix it within 15-30 minutes, including any work required to isolate the issue.
  • Students who attend are probably using git (and version control in general) for the first time, and will probably spend a substantial amount of time cleaning up their patch before submitting, and discussing good commit log messages with mentors at the event.
  • Documentation bugs are totally germane, so long as the documentation issue doesn't require an extremely deep understanding of the project or code.

To get a sense of good tasks from past events:

(We'll add more over time.)