|
|
| Line 1: |
Line 1: |
| __NOTOC__ | | __NOTOC__ |
| | {| border="1" |
| | |- |
| | |'''Title''' || Bug Gardening / Bug Triage / Bug Grooming / |
| | |- |
| | |'''Overview''' || Most projects have a backlog of bugs that need to be periodically “gardened.” Sometimes there are even old bugs that may have already been fixed that just haven’t been closed in the system. This module familiarizes students with bug gardening (/bug triage/ bug grooming) techniques, *and* helps the community by doing some of that gardening. |
| | |- |
| | |'''Prerequisite Knowledge''' || Students should be familiar with how bug trackers work -- see [[http://foss2serve.org/index.php/Bug_Tracker_Activity| Bug Tracker Activity]] |
| | |- |
| | |'''Learning Objectives''' || What should the student be able to do after completing completed this activity? |
| | |} |
|
| |
|
| {{Learning Activity Overview
| | === Background: === |
| |title=
| | If the project you're working with has a guide for how to triage bugs, the students should read that first. |
| Intro to IRC (Internet Relay Chat)
| |
| |overview=
| |
| Learners will gain a basic understanding of IRC (Internet Relay Chat) as well as the role that IRC plays in open source software development.
| |
| Participants will learn about IRC etiquette and explore the interactions that occur between members of an open source community.
| |
| |prerequisites=
| |
| None.
| |
| |objectives=
| |
| # Describe the importance of IRC as it relates to open source software development.
| |
| # Connect to an IRC server and join a channel.
| |
| # Participate in a brief interaction on an IRC channel.
| |
| |process skills=
| |
| }}
| |
|
| |
|
| === Background ===
| | Here are two examples: |
| | * [http://www.gluster.org/community/documentation/index.php/Bug_triage Gluster Bug Triage Guidelines] and their accompanying [http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle Lifecycle of a Bug] |
| | * [https://www.mediawiki.org/wiki/Bug_management/How_to_triage Bug Management - How to Triage (MediaWiki)] |
|
| |
|
| IRC (Internet Relay Chat) is an essential tool used by open source software developers. It allows members of the community, or those interested in becoming involved in the community, to communicate 24/7, regardless of their geographic location. IRC is much like Instant Messaging with a group.
| | The student should be familiar with how to use the bug tracker (see [[Bug_Tracker_Activity|Bug Tracker Activity]]) |
|
| |
|
| Bear in mind that ‘talking’ is not always a requirement. You will learn a great deal by ‘listening’, especially in the beginning. When you join a channel, it is not necessary to identify yourself or to say hi, you can simply 'lurk'. Feel free to ask questions, and note that it is not necessary to ask first if you can ask a question.
| | If you're working with a specific open source project, you may want to ask the project (via IRC or mailing list) if there are a particular set of bugs that your students should focus on. For example, in the Gluster project I noted above, if a bug is tagged POST it means that an initial patch for a bug has been put into the Gerrit code review tool. If there |
| | is a very old bug that's marked POST, there's a decent likelihood that the patch has been incorporated into the project and the bug wasn't closed for whatever reason. If your students can verify this and close the bug, that's valuable. |
|
| |
|
| IRC resources:
| | Other projects may have similar situations that are worth asking about. |
| * [http://www.irchelp.org IRC Help: tutorials and more]
| |
| * http://teachingopensource.org/index.php/IRC
| |
| * [http://www.ircbeginner.com/ircinfo/ircc-commands.html A list of IRC commands]
| |
| * [http://www.greenday.net/chat/commands.html More complete list of IRC Commands]
| |
|
| |
|
| === Directions === | | === Directions: === |
| Throughout this activity you will be asked to answer questions, make observations, and may wish to take notes. These should be posted to your wiki page.
| | This activity is best performed in groups of two or three students, who can work together to: |
| | * identify a "suspect" bug in the bug tracker, |
| | * test it to see if it still exists, and |
| | * if it doesn't, close the bug. |
|
| |
|
| ==== Part 1 – Walk through of IRC Conversation ====
| | Identifying the "suspect" bugs will be easiest if you have information from the project about their bug lifecycle or have information directly from the project about which bugs to focus on, but even in the absence of that information, there are some other clues that can be used to identify bugs that might no longer be bugs. |
|
| |
|
| Download this sample [[Media:mouseTrapMeeting.pdf | IRC Conversation]]
| | One thing to look at is the version number of the software that the bug was reported against (versus the one that's current now). If the bug is for a version that's several releases out of date, there's a good likelihood that the issue may have been fixed (or may have just become irrelevant) in the meantime. |
|
| |
|
| This conversation is part of a meeting being run with a '''meetbot'''.
| | Another possible hint is the date on the bug: bugs that were reported years ago may have been fixed and are probably worth looking at first. |
| A [http://wiki.debian.org/MeetBot meetbot] is a type of "bot" (or program that simulates a human activity) that works in IRC channels to help take notes for a meeting.
| |
| Note the dark green entries in the conversation that begin with a hashmark. These are meetbot commands.
| |
| * The first line of the conversation shows "darci" starting the meeting.
| |
| * "totally" is the name of the meetbot.
| |
| * The #topics command sets the topic of the conversation and is one of several commands.
| |
|
| |
|
| As you review the conversation, you should:
| | === Deliverables: === |
| # Pay attention to the interactions that occur between community members.
| | What will the student hand in? |
| # Ignore the technical terms.
| |
| # Accept that the content may be beyond your understanding at this point, your first step in being productively lost.
| |
| # Answer the following questions on your wiki page:
| |
| #* How do people interact?
| |
| #* What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix?
| |
| #* Are there any terms that seem to have special meaning?
| |
| #* Can you make any other observations?
| |
| # Now look at the [[Media:mousetrapBot2013-03-01.pdf | results of the meetbot]]. This shows you how each meetbot command is formatted into a legible page that summarizes the meeting. Some additional formatting may be needed, but it certainly provides a great starting point. Here's a link to the final version of the [https://wiki.gnome.org/Projects/MouseTrap/Meetings/20130301 meeting notes].
| |
| #* Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?
| |
|
| |
|
| ==== Part 2 – Install and Start an IRC Client ==== | | === Assessment: === |
| | How will the activity be graded? |
| | |
| | How will learning will be measured? |
|
| |
|
| There are many IRC clients to choose from, below is a brief list of suggestions:
| | Include sample assessment questions/rubrics. |
| # Windows and Linux: Hexchat (https://hexchat.github.io/) or Pidgin (https://pidgin.im/)
| |
| # Mac OS X: Colloquy (http://colloquy.info/)
| |
| # Firefox add-on: ChatZilla (https://addons.mozilla.org/en-US/firefox/addon/chatzilla/) is a multi-platform add-on that will work on Windows, Linux and Mac OS X.
| |
|
| |
|
| For example, if you have Firefox running, follow these steps to add ChatZilla.
| | === Comments: === |
| | What should the instructor know before using this activity? |
|
| |
|
| # Click '''Tools''' from the main menu and then choose '''Add-ons'''. The Get Add-ons tab should be selected on the left. If you don’t see the main menu, click the menu button in the upper, right corner, and select Add-ons.
| | What are some likely difficulties that an instructor may encounter using this activity? |
| # Scroll down and click the '''See more add-ons!''' button.
| |
| # Type ChatZilla in the search box found in the upper, right corner.
| |
| # Hover over the ChatZilla add-on and then click the '''Add to Firefox''' button to the right of the ChatZilla add-on. Note that ChatZilla is available in a number of languages, so be sure to select the appropriate one.
| |
| # Restart Firefox.
| |
|
| |
|
| Note that there are some locations or situations where the IRC port is blocked. In such cases you may want to use a web-based client:
| | === Additional Information: === |
| # Kiwiirc, supports the freenode server and you can access the foss2serve channel from here. - https://kiwiirc.com/client/irc.freenode.net/
| | {| border="1" |
| # Mibbit, allows you to connect to a variety of servers. - http://www.mibbit.com/
| |
| | |
| ==== Part 3 – Join and Observe Channel Discussion ====
| |
| The GNOME Accessibility Team (https://wiki.gnome.org/Accessibility) utilizes a fairly active channel. You should observe the #a11y channel for 24 hours and no, you do not need to be physically present for this length of time! You can join the channel and let the IRC client record the communications that occur.
| |
| | |
| # Connect to the server via the command: /server irc.gnome.org
| |
| # Join the a11y channel via the command: /join #a11y (note that 1 is the number one, not the letter L)
| |
| # Summarize your observations on your wiki page.
| |
| #* Pay particular attention to the ways that the communication in this channel differs from the sample dialog you examined in Part 1
| |
| | |
| ==== Part 4 – (Optional - Make your own channel and experiment) ====
| |
| | |
| Sometimes the best way to figure out what's possible is just to play around and know you're not going to step on anyone's toes. In IRC you can create a channel by typing
| |
| /join #channelname
| |
| (and you can make "channelname" whatever made up thing that you want!).
| |
| | |
| A variant of that is that if you type
| |
| /join #yournick
| |
| and no one has created the channel #yournick on that IRC server then a new channel called #yournick will be created and you'll automatically have Ops privileges. This is a fun way to experiment with Ops privs!
| |
| | |
| Next, try one of the most useful commands (for almost any system, anywhere): help
| |
| * Remember to precede it with the /, as that's what tells the client that it's a command, not text to be sent.
| |
| * Invite another student to the your channel and try some of the commands that you can only do with Ops privileges
| |
| * Record the commands you tried and what they did (in your own words) on your wiki page.
| |
| | |
| === Deliverables ===
| |
| | |
| POSSE: Be ready to participate in the upcoming IRC meeting:
| |
| * Have the appropriate IRC client installed and running
| |
| * Test that you can connect to the network
| |
| * Test that you can access freenode and the foss2serve channel
| |
| ** /server irc.freenode.net
| |
| ** /join #foss2serve
| |
| | |
| POSSE and Students will deliver:
| |
| # For Part 1, their observations/answers to the following questions:
| |
| #* How do people interact?
| |
| #* What is the pattern of communication?
| |
| #* Are there any terms that seem to have special meaning?
| |
| #* What advantages might IRC have over other real-time communication methods (like Google Chat or Facebook Messenger?) Are there potential disadvantages?
| |
| #* Can you make any other observations?
| |
| #* Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?
| |
| # For Part 2: nothing to deliver, should have successfully installed IRC client
| |
| # For Part 3: observations of the #a11y channel communications and how they differed from the sample dialog in Part 1.
| |
| # For Part 4 (optional): a list of at least 5 commands that will work in the channel that was created, and what they mean.
| |
| | |
| = Notes for Instructors =
| |
| The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.
| |
| | |
| === Assessment ===
| |
| Some possible questions:
| |
| * For what purposes do FOSS projects use IRC channels?
| |
| * Why choose IRC over another synchronous collaboration method (like a conference call)?
| |
| * How can IRC be used to facilitate project management?
| |
| * In your own words, explain how to find a channel and join it for whichever IRC client you prefer.
| |
| | |
| | |
| {| class="wikitable" | |
| |- | | |- |
| |'''Criteria''' ||'''Level 1 (fail)'''||'''Level 2 (pass)'''||'''Level 3 (good)'''||'''Level 4 (exceptional)''' | | |'''Knowledge Area/Knowledge Unit''' || Software Development Fundamentals//Software Verification and Validation |
| | |- |
| | |'''Topic''' || Defect tracking |
| | |- |
| | |'''Level of Difficulty''' || Medium (requires some understanding of the intended functionality of the software, ability to use bug tracking software, and critical thinking skills) |
| | |- |
| | |'''Estimated Time to Completion''' || How long should it take for the student to complete the activity? |
| |- | | |- |
| |Understanding of importance of IRC in open source (from observations of IRC log) || Did not attempt observations || Minimum effort put into observations (one statement per question, for example) || Complete observations || Well thought-out observations that tie the material back to other knowledge (bonus question also a nice addition) | | |'''Materials/Environment''' || Student needs access to the project's bug tracker, internet access |
| |- | | |- |
| |Ability to connect to an IRC server and join a channel || Did not attempt || Installed client but did not join channel || Installed client, joined channel || Installed client, joined channel, made good observations of project | | |'''Author''' || Gina Likins |
| |- | | |- |
| |Become familiar with the interactions that occur in an IRC channel (from Observations of HFOSS project) || Did not attempt observations || Minimum effort put into observations (one statement per question, for example) || Complete observations || Well thought-out observations that tie the material back to other knowledge | | |'''Source''' || [http://blog.smartbear.com/programming/ 14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star] |
| |- | | |- |
| | |'''License''' || This work is licensed under a [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License] |
| |} | | |} |
|
| |
|
| === Comments === | | === Suggestions for the Open Source Project: === |
|
| |
|
| * Some projects have multiple channels. There may be one for developers, another for documentation and another still for end users. These should all be listed on the project website. See, for example, [http://wiki.sahanafoundation.org/community/chat Sahana], which has:
| | Your community should have specific expectations around [support] that are published [somewhere]. For example, if your code will only work on Fedora versions newer than 19, then specify that. |
| ** Sahana : for general Sahana developer or user support from the community (starting point for most discussions)
| |
| ** Sahana-Meeting : for scheduled Sahana meetings
| |
| ** Sahana-Agasti : for Sahana Agasti-specific developer discussions
| |
| ** Sahana-Eden : for Sahana Eden-specific developer discussions
| |
| ** Sahana-GIS : for Sahana GIS-specific discussions
| |
|
| |
|
| * Depending on the project, its size, and the amount of activity on a project's channel, it may be necessary to determine an appropriate day for this observation. If there is a specific day/tim that the developers meet, you might want to schedule your observation for this day. You can join the channel and identify yourself as _afk (away from keyboard, for example joe_afk using the /nick command). When you return the following day, you will be able to observe the communication that occurred during the previous 24 hour period.
| | If there are a set of bugs that it would be more helpful to have someone verify, then marking those in some way would help the instructor. |
|
| |
|
| *Note that many of the POSSE and OpenFE team hang out in the foss2serve channel throughout the day:
| |
| ** Connect to the server via the command: /server irc.freenode.net
| |
| ** Join the foss2serve channel via the command: /join #foss2serve
| |
| ** Come join us!!!
| |
|
| |
|
| {{Learning Activity Info
| |
| |acm unit=
| |
| HCI/Collaboration and Communication, HCI/Foundations, SE/Software Project Management
| |
| |acm topic=
| |
| * Synchronous Group Communication
| |
| * Social models that inform interaction design, e.g., culture, communication, networks and organizations (*why* IRC and not something else)
| |
| * Team Participation/Team Management
| |
| |difficulty=
| |
| Easy
| |
| |time=
| |
| 60-75 minutes
| |
| |environment=
| |
| Internet access, a Web browser and an IRC client.
| |
| |author=
| |
| Darci Burge, Heidi Ellis & Gina Likins
| |
| |source=
| |
| [http://xcitegroup.org/softhum/doku.php?id=f:assignments Communication and Community]
| |
| |license=
| |
| {{License CC BY SA}}
| |
| }}
| |
|
| |
|
| === Suggestions for the Open Source Project ===
| | -------------------- |
| | This work is licensed under a |
| | [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License] |
|
| |
|
| What channels does your project use? Which would be most useful for students to join?
| | [[File:CC_license.png]] |
|
| |
|
| [[Category:Instructor Activities]] | | [[Category: Learning_Activity]] |
| [[Category:Learning Activity]] | | [[Category: Quality_and_Testing]] |
| [[Category:Communication and Tools]]
| |
| [[Category:IRC]]
| |
| [[Category:CS Principles]]
| |
| [[Category:Ready To Go]]
| |
| Title |
Bug Gardening / Bug Triage / Bug Grooming /
|
| Overview |
Most projects have a backlog of bugs that need to be periodically “gardened.” Sometimes there are even old bugs that may have already been fixed that just haven’t been closed in the system. This module familiarizes students with bug gardening (/bug triage/ bug grooming) techniques, *and* helps the community by doing some of that gardening.
|
| Prerequisite Knowledge |
Students should be familiar with how bug trackers work -- see [Bug Tracker Activity]
|
| Learning Objectives |
What should the student be able to do after completing completed this activity?
|
Background:
If the project you're working with has a guide for how to triage bugs, the students should read that first.
Here are two examples:
The student should be familiar with how to use the bug tracker (see Bug Tracker Activity)
If you're working with a specific open source project, you may want to ask the project (via IRC or mailing list) if there are a particular set of bugs that your students should focus on. For example, in the Gluster project I noted above, if a bug is tagged POST it means that an initial patch for a bug has been put into the Gerrit code review tool. If there
is a very old bug that's marked POST, there's a decent likelihood that the patch has been incorporated into the project and the bug wasn't closed for whatever reason. If your students can verify this and close the bug, that's valuable.
Other projects may have similar situations that are worth asking about.
Directions:
This activity is best performed in groups of two or three students, who can work together to:
- identify a "suspect" bug in the bug tracker,
- test it to see if it still exists, and
- if it doesn't, close the bug.
Identifying the "suspect" bugs will be easiest if you have information from the project about their bug lifecycle or have information directly from the project about which bugs to focus on, but even in the absence of that information, there are some other clues that can be used to identify bugs that might no longer be bugs.
One thing to look at is the version number of the software that the bug was reported against (versus the one that's current now). If the bug is for a version that's several releases out of date, there's a good likelihood that the issue may have been fixed (or may have just become irrelevant) in the meantime.
Another possible hint is the date on the bug: bugs that were reported years ago may have been fixed and are probably worth looking at first.
Deliverables:
What will the student hand in?
Assessment:
How will the activity be graded?
How will learning will be measured?
Include sample assessment questions/rubrics.
What should the instructor know before using this activity?
What are some likely difficulties that an instructor may encounter using this activity?
Additional Information:
Suggestions for the Open Source Project:
Your community should have specific expectations around [support] that are published [somewhere]. For example, if your code will only work on Fedora versions newer than 19, then specify that.
If there are a set of bugs that it would be more helpful to have someone verify, then marking those in some way would help the instructor.
This work is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International License
File:CC license.png
