Revision as of 22:03, 14 May 2013 (view source) imported>Shauna (Created page with "__toc__ == Intro to the project == == Definition == * The typical attendee has 1-2 semesters of programming background (naturally this depends on the year they are, and the...")		Revision as of 22:19, 14 May 2013 (view source) imported>Shauna No edit summary Newer edit →
Line 2: == Intro to the project == 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. == 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? == Definition == * 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. == Examples of good first tasks ==

First Task Definition: Difference between revisions

First Task Definition (view source)

Revision as of 22:19, 14 May 2013