[OH-Dev] improving our 'first tasks' for Open Source Comes to Campus Events

[Shauna Gordon-McKeon]

**

*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.*


So we’re hoping to spend the next couple of months improving our
bug/contribution-finding process.  This will involve a few phases.

1.  Defining what makes a good bug.

2.  Creating an efficient system for finding and gathering good bugs.

3.  Documenting, publicizing, and using the system.
*
*
**
*

I’ve created a wiki page, First Task
Definition<https://openhatch.org/wiki/First_Task_Definition>,
for us to document phase I.
*
*


*
*

The wiki page has two sections I'm especially interested in getting your
feedback on.
*

**
**
*

Bad Task Experiences
*
*


*
What problems have you - either as a mentor at OSCTC events, or in your own
work as a contributor - run across?  Please list as many issues, in as much
detail, as you like.

An example:

One issue we've had is when the project is very large and there's no
guidance as to where a given fix might need to be made.  It's unclear to me
how much guidance is necessary - I think we should perhaps require the task
come with at least a segment of the project to look in ("Look inside the
"demos" folder"), but perhaps we should ask that problems be identified
down to the file?

**
**
*

Relevant Questions
*
*


*
Here are a list of questions that may help us with our definition.  Please
feel free to answer them at any length, and/or to add other questions.

- 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 the project use? For example, git vs subversion vs
other version control systems?
- What types of issues are we looking for? Bugs vs feature requests vs
documentation vs design vs helping users on lists?
- How long should issues ideally take to address?
- Will the attendee likely receive quick, friendly, useful feedback on
their contribution from a maintainer or community member?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20130516/8addba1c/attachment.html>