Curated First Tasks: Difference between revisions

From OpenHatch wiki
Content added Content deleted
imported>Shauna
imported>Shauna
No edit summary
Line 1: Line 1:
__toc__
__toc__


===Context & Process===
===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 [[#What_makes_for_a_good_bug.3F | 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.
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 [[#What_makes_for_a_good_bug.3F | 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.

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 [[#Project_List | list of open source projects]] which we will work with to collect good beginner bugs for our events. Where possible, we will:
Our intention is to create a [[#Project_List | list of open source projects]] which we will work with to collect good beginner bugs for our events. Where possible, we will:

* email maintainers and/or the broader community to announce our intentions
* email maintainers and/or the broader community to announce our intentions
* create an Open Hatch account in that project's bug tracker which can claim and/or be assigned bite sized bugs
* create an Open Hatch account in that project's bug tracker which can claim and/or be assigned bite sized bugs
Line 11: Line 16:


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 data, please release it."
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 data, please release it."

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.

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


===Bug List===
===Bug List===
Line 25: Line 26:


[https://docs.google.com/spreadsheet/ccc?key=0AoHP1ey91UqPdC1EUFV4aXBETmY3bFBzTFhpdG1ISEE#gid=0 Link to current google spreadsheet project list.]
[https://docs.google.com/spreadsheet/ccc?key=0AoHP1ey91UqPdC1EUFV4aXBETmY3bFBzTFhpdG1ISEE#gid=0 Link to current google spreadsheet project list.]

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

Revision as of 23:27, 4 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.

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. Where possible, we will:

  • email maintainers and/or the broader community to announce our intentions
  • 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 data, please release it."

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.

Project List

Install google spreadsheets widget code?

Link to current google spreadsheet project list.

What makes for a good bug?