Anonymous user
First Task Definition: Difference between revisions
→Relevant questions
imported>Shauna No edit summary |
imported>Paulproteus |
||
| (15 intermediate revisions by one other user not shown) | |||
Line 1:
__toc__
==
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.
==
===Relevant questions===
Some questions that might help us create our definition:
* Set up:
Line 22 ⟶ 26:
** 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? '''
== Examples of good first tasks ==
| |||