Difference between pages "Project Evaluation Activity V1" and "Intro to Bug Trackers (Activity)"

From TeachingOpenSource
(Difference between pages)
 
 
Line 1: Line 1:
== Project Evaluation ==
== Bug Trackers ==


=== Preparation: ===
=== Preparation: ===
Line 5: Line 5:
{| border="1"
{| border="1"
|-  
|-  
|'''Description''' || Learners will gain an understanding of the breadth of available FOSS projects. Learners will also gain an understanding of the identifying characteristics of FOSS projects including pattern of contributions, patterns of commits, programming languages used, and more.
|'''Description''' || Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project.  
|-
|-
|'''Source''' ||
|'''Source''' ||None.
|-
|-
|'''Prerequisite Knowledge''' || Completion of Browsing a Forge Activity or understanding of SourceForge and Ohloh; Understanding of course in which students will be participating in an HFOSS project.
|'''Prerequisite Knowledge''' || None.
|-
|-
|'''Estimated Time to Completion''' || 60-90 minutes
|'''Estimated Time to Completion''' || 60 minutes
|-
|-
|'''Learning Objectives''' ||Ability to: 1)Utilize the rubric to identify likely HFOSS projects.  
|'''Learning Objectives''' ||Ability to: 1) Describe the role that a bug tracker plays in a FOSS project, 2) Describe the different types of issues stored in a bug tracker and their priorities, and 3)Identify and track the status of a particular bug in a project.  
|-
|-
|'''Materials/Environment''' || [http://xcitegroup.org/softhum/lib/exe/fetch.php?media=g:evalfossprojects.doc SIGCSE paper] Access to Internet/Web and web browser.
|'''Materials/Environment''' || Access to Internet/Web and web browser.
|-
|-
|'''Additional Information''' || Lists of projects
|'''Additional Information''' || ?
|-
|-
|'''Rights''' || Licensed CC BY-SA
|'''Rights''' || Licensed CC BY-SA
|-
|'''Turn In''' || Wiki posting describing the results of your exploration below.
|}
|}


=== Background: ===
=== Background: ===
This 8 minute video gives you an overview of rubric and how it is used.
Bug tracking systems are a form of change management and organization used by FOSS projects. Bug trackers do far more than simply keep track of bugs. They also are used to hold new feature requests, patches, and some tasks. Bug trackers are also called request trackers, issue trackers, request trackers and ticket systems. Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.


[ Watch the video.]
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]
* [http://en.wikipedia.org/wiki/Bug_tracking_system Wikipedia's page on Bug Tracking Systems]


=== Directions: ===
=== Directions: ===
====Part 1-Evaluate Mission Critical Criteria====
We will begin by looking at a typical Bugzilla instance for a project. We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team.  
'''Evaluate Viability'''
#Size/Scale/Complexity
##Go to Ohloh.net, type Mifos into the Search Projects box, Click on Mifos to see the Project Summary page
##Scroll down to the Community area and calculate the average number of contributors in the last month.  The average was 9 so it passed the minimum average number of contributors metric of 6.
##Go to the Mifos web page and choose Tech Overview from the Contributors tab.  From examination of the technology stack, the architecture looks modular and further search shows it is documented elsewhere on the site. 
##Result-Based on the modular design and meeting the minimum average number of contributors metric, the project is scored a 2 for size/scale/complexity.
#Activity
##Return to the Mifos project summary page in Ohloh.  Scroll to the Activity area on the page.
##Compute the 12-month average of commits.  The 12-month average was about 108, above the minimum average level of commits recommended for activity.
##Result-Because commits exceed the favorable level of activity for this project it may be a little large/complex.  However, still appears manageable, the project is score a 2 for activity.
#Community
##Examine download activity
###Go to Sourceforge.net and enter Mifos into the search box. 
###Choose Mifos-Microfinance Open Source from the search results.
###Click on the number of downloads that is listed on the project page.
###Change the date range to give a graph of downloads over the last year. 
##Examine mailing list activity. 
###Return to the Mifos web page.  From the Contributor tab choose the Join the Mailing List link to get access to the project mailing list. 
###Once granted access, examine the Developer mailing list for activity.
##Examine the IRC channel
###Again from the Contributor tab on the Mifos web page, choose the IRC link. 
###Examine the IRC channel for activity.
##Result-Downloads appear steady so the project has a community of users.  Developers are responsive on mailing list and developers have a presence on IRC.  Project is scored a 3.
 
'''Evaluate Approachability'''
 
Here you are evaluating a project's on-ramp to contribution, scoring as follows:


::1-Insufficient-Few or no pointers on how to become involved.
== Part 1 - Bug Reports ==
# Open a browser and go to the [https://bugzilla.gnome.org/buglist.cgi?type0-7-0=notequals;field0-3-0=product;keywords=accessibility;type0-1-0=notequals;type0-5-0=notequals;keywords_type=allwords;value0-5-0=accerciser;value0-4-0=at-poke;field0-1-0=product;field0-0-0=product;type0-4-0=notequals;field0-6-0=product;value0-3-0=gnome-mag;field0-7-0=product;query_format=advanced;value0-2-0=Dasher;value0-6-0=gnome-speech;value0-1-0=Gok;type0-3-0=notequals;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;field0-2-0=product;field0-5-0=product;field0-4-0=product;type0-6-0=notequals;type0-0-0=notequals;value0-0-0=Orca;type0-2-0=notequals GNOME Accessibility Bugs]
# Define what each of the column names below indicate. Include the range of possible values for b-g:
## ID
## Sev
## Pri
## OS
## Product
## Status
## Resolution
## Summary
# Describe how you discovered the definitions and How did you find the information from above?
# Identify the order in which the bugs are initially displayed?
# What is the meaning of the blue shading of some bug reports?
# What is the meaning of the colors used when describing a bug (red, gray, black)?
# Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).
## Identify when the bug was submitted.
## Identify if there has been recent discussion about the bug?
## Is the bug current?
## Is the bug assigned? To whom?
## Describe what you would need to do to fix the bug. 
# Repeat the previous step with a different kind of bug.  


::2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.
== Part 2 - Collective Reports ==
# Click on the “Reports” link on the top of the page.
# How many bug reports were opened in the last week? How many were closed?
# What was the general trend last week? Were more bugs opened than closed or vice versa?
# Who were the top three bug closers? Why is this important to know?
# Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists?
# Who are the top three contributors of patches?
# Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers?
# Click on the “Generic Reports” link.
# Plot the Severity of each Version of the Accessibility features of Empathy.
# What other reports can you generate?


::3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.


#Link to get started-From the Contributors tab on the Mifos web page there is a Get Started page with links to what Mifos is, how to contribute, community processes, and tools used. 
#List of suggestions for things to do - Clicking the Get Involved link on the Get Started page provides a list of ways to contribute including testing, translation, development and documentation.  There is also a volunteer bug queue listed as a good way for developers to get started. 
#Detailed instructions-Instructions are provided in many areas including process, architecture, licensing, product functionality, and developer documentation.
#Result-Was scored a 3. 
'''Evaluate Suitability'''
#Appropriate Artifacts -Since evaluation is dependent on class objectives, in this example we'll assume an objective is to learn the process of working in authentic development project through contributing bug fixes.
##Opportunities to contribute bug fixes - Examined the volunteer bite-sized bug queue accessible from the Volunteer page under the Contributors tab on the Mifos web page.  There were 10 open bugs for new contributors.  There were many more listed for more experienced contributors.
##Documentation on how to contribute bug fixes - From the Tech Overview page accessible from the Contributors tab on the web site there is a link to details on the code submission process. 
##Result - May score a 2 or 3, depends on number of bugs and class size.
#Contributor Support-Does the project have a high volume of guidance to help students as they learn?
##Are communication tools documented?-
##Do developers have a web presence?-
##Are operating processed documented?-
##Do questions posed have timely and supportive answers?-
====Part 2-Evaluate Secondary Criteria====


[[Category: Foss2serve]]
[[Category: Foss2serve]]
[[Category: Learning_Activity]]
[[Category: Learning_Activity]]
'''Evaluate Viability'''
#Domain
#Maturity
#User Support
#Roadmap
'''Evaluate Approachability'''
#Contribution Types
#Openness to Contributions
#Student Friendliness
'''Evaluate Suitability'''
#Project Description
#Platform
#Development Features

Revision as of 22:26, 7 April 2013

Bug Trackers

Preparation:

Description Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project.
Source None.
Prerequisite Knowledge None.
Estimated Time to Completion 60 minutes
Learning Objectives Ability to: 1) Describe the role that a bug tracker plays in a FOSS project, 2) Describe the different types of issues stored in a bug tracker and their priorities, and 3)Identify and track the status of a particular bug in a project.
Materials/Environment Access to Internet/Web and web browser.
Additional Information ?
Rights Licensed CC BY-SA
Turn In Wiki posting describing the results of your exploration below.

Background:

Bug tracking systems are a form of change management and organization used by FOSS projects. Bug trackers do far more than simply keep track of bugs. They also are used to hold new feature requests, patches, and some tasks. Bug trackers are also called request trackers, issue trackers, request trackers and ticket systems. Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.

Directions:

We will begin by looking at a typical Bugzilla instance for a project. We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team.

Part 1 - Bug Reports

  1. Open a browser and go to the GNOME Accessibility Bugs
  2. Define what each of the column names below indicate. Include the range of possible values for b-g:
    1. ID
    2. Sev
    3. Pri
    4. OS
    5. Product
    6. Status
    7. Resolution
    8. Summary
  3. Describe how you discovered the definitions and How did you find the information from above?
  4. Identify the order in which the bugs are initially displayed?
  5. What is the meaning of the blue shading of some bug reports?
  6. What is the meaning of the colors used when describing a bug (red, gray, black)?
  7. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).
    1. Identify when the bug was submitted.
    2. Identify if there has been recent discussion about the bug?
    3. Is the bug current?
    4. Is the bug assigned? To whom?
    5. Describe what you would need to do to fix the bug.
  8. Repeat the previous step with a different kind of bug.

Part 2 - Collective Reports

  1. Click on the “Reports” link on the top of the page.
  2. How many bug reports were opened in the last week? How many were closed?
  3. What was the general trend last week? Were more bugs opened than closed or vice versa?
  4. Who were the top three bug closers? Why is this important to know?
  5. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists?
  6. Who are the top three contributors of patches?
  7. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers?
  8. Click on the “Generic Reports” link.
  9. Plot the Severity of each Version of the Accessibility features of Empathy.
  10. What other reports can you generate?
Retrieved from "https://teachingopensource.org/index.php?title=Project_Evaluation_Activity_V1&oldid=4650"
Powered by MediaWiki