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

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


{{Learning Activity Overview
=== Preparation: ===
|title=
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 ===
{| border="1"
 
|-
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.  
|'''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. 
|-
|'''Source''' ||
|-
|'''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.
|-
|'''Estimated Time to Completion''' || 60-90 minutes
|-
|'''Learning Objectives''' ||Ability to: 1)Utilize the rubric to identify likely HFOSS projects.
|-
|'''Materials/Environment''' || [http://xcitegroup.org/softhum/lib/exe/fetch.php?media=g:evalfossprojects.doc SIGCSE paper] Access to Internet/Web and web browser.
|-
|'''Additional Information''' || Lists of projects
|-
|'''Rights''' || Licensed CC BY-SA
|}


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.
=== Background: ===
This 8 minute video gives you an overview of rubric and how it is used.


IRC resources:
[ Watch the video.]
* [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 a walkthrough of evaluating the Mifos project. 
====Part 1-Evaluate Mission Critical Criteria====
'''Evaluate Viability'''
#Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complex.  One heuristic to use is the number of contributors as an indicator project complexity.
##Go to Ohloh.net, type Mifos into the Search Projects box, in results 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 12 months.  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 - To support student participation a project should be reasonably active.  Number of committers can be used as an indicator of 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, much higher than 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 scored a 2 for activity.
#:
#Community - A suitable project has an active user community.  While it is difficult to quantitatively evaluate the activity of a user community, some indicators include a regular history of project downloads and documentation updates over time, current activity on user mailing lists, and testimonials on the project web site.
##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.


==== Part 1 – Walk through of IRC Conversation ====
'''Evaluate Approachability'''


Download this sample [[Media:mouseTrapMeeting.pdf | IRC Conversation]]
Here you are evaluating a project's on-ramp to contribution, scoring as follows:


This conversation is part of a meeting being run with a '''meetbot'''.
::1-Insufficient-Few or no pointers on how to become involved.
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:
# Pay attention to the interactions that occur between community members.
# 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 ====
 
There are many IRC clients to choose from, below is a brief list of suggestions:
# 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.
 
# 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.
# 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:
# Kiwiirc, supports the freenode server and you can access the foss2serve channel from here. - https://kiwiirc.com/client/irc.freenode.net/
# 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
 
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)'''
|-
|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)       
|-
|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         
|-
|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
|-
|}


=== Comments ===
::2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.


* 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:
::3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.
** 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.
#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.


*Note that many of the POSSE and OpenFE team hang out in the foss2serve channel throughout the day:
'''Evaluate Suitability'''
** Connect to the server via the command:   /server irc.freenode.net
#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.
** Join the foss2serve channel via the command: /join #foss2serve
##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.
** Come join us!!!
##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 1, 2 or 3 depending on the number of bugs suitable for students to tackle and class size.
#Contributor Support-Does the project have a high volume of guidance to help students as they learn?
##Are communication tools documented?-Communication tools are documented under the Collaboration and Communication section of the Development Tools page which can be accessed from the Contributors tab on the Mifos web site.  Instructions on how to access the mailing lists with tips on how to participate are available from the Communications page under the Community tab. 
##Do developers have a web presence?-Examination of [http://ci.mifos.org/irclogs/%23mifos/ IRC logs] shows scattered activity over the last week.
##Are operating processed documented?-Links to information about coding standards, code submission process, and commit privileges process can be found on the Tech Overview page accessible from the Contributors tab.  The process for making feature requests and for prioritizing feature request is available on the Roadmap page accessible from the Product tab.
##Do questions posed have timely and supportive answers?-Responses to [https://groups.google.com/forum/#!forum/mifosusers user mailing list] and [https://groups.google.com/forum/#!forum/mifosdeveloper developer mailing list] over the last month have timely and supportive responses.
##Result - Not a lot of activity on IRC, but mailing lists show lots of timely feedback and communication methods and operating procedures are well documented, score a 3.


{{Learning Activity Info
====Part 2-Evaluate Secondary Criteria====
|acm unit=
Since no mission-critical criteria were scored lower than a 2 the project is then evaluated on secondary criteria. Otherwise, the project would have been considered not suitable for student participation.
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 ===
'''Evaluate Viability'''
#Domain
##Does this project require domain knowledge that may be difficult for students to learn? - As a domain microfinance students should be able to grasp it well enough to contribute a bug fix, which is the learning objective assumed in this example.
##Result - Score a 2 since the domain isn’t as simple to grasp as say a desktop application for word processing or compressing files.
#Maturity
##To have the organization to support student learning, the project should have at least one stable production release - The roadmap page accessible from product tab on the Mifos web site lists releases.
##Result - The Download Mifos page accessible from the Product page says 2.6.0 is the 4th major community-supported release.  Scored a 3.
#User Support
##The project should have clear instructions for downloading, installing, and using the project - There is a demo server, video, and slide presentation that explains system functionality.  This information can be found looking at pages listed under the Product tab that can be used to learn about the system.  There is also a user manual available from the Support tab.  On the Download Mifos page, also listed under the Product tab, there are detailed instructions related to installation, configuration, system requirements, and troubleshooting.
##Result - Given the wealth of detailed documentation, score a 3.
#Roadmap
##Student learning is best supported by projects that have a roadmap that includes new feature development, a method for users to submit new feature requests and a process for identifying how new features are prioritized - The process for making feature requests and for prioritizing feature request is available on the Roadmap page accessible from the Product tab.  The Roadmap page has features were implemented in the last release, but no listing for the next release.
##Result - Scored a 2 because there is no information listed for feature planning in the next release.


What channels does your project use? Which would be most useful for students to join?
'''Evaluate Approachability'''
#Contribution Types
##Does the project contain opportunities for multiple types of contribution and of the type that fits the class? - There are multiple projects for testers, tech writers, and developers.  These can be seen on the [http://mifos.org/contributors/volunteer-projects Volunteer Projects page].
##Result - May be a 1, 2 or 3 depending on whether the number of bugs is suitable for students is enough given the class size.
#Openness to Contributions
##Acceptance of a student contribution to a project provides valuable affirmation to student learning.  Determine whether the project accepts student patches. - The process for contribution is documented.
##Result - Score a 3 because the contribution process is documented.
#Student Friendliness
## Do community members moderate the tone of communication?  Review mailing lists and IRC to gauge tone - Review of [https://groups.google.com/forum/#!forum/mifosusers user mailing list] and [https://groups.google.com/forum/#!forum/mifosdeveloper developer mailing list] and [http://ci.mifos.org/irclogs/%23mifos/ IRC logs] during evaluation of contributor support showed a positive tone during communication.
##Result - Score a 3, no inappropriate or demeaning messages. 
'''Evaluate Suitability'''
#Project Description
##Students must be able to understand the purpose of the project.  Does the project clearly describe the product? Can students understand the intended uses of the product? - The About tab on the web page lists the vision for the product and how it is used by microfinance institutions.
##Result - Score a 3, how the product is used and the vision for it is well documented and should be understandable by students. 
#Platform
##What software and hardware platform does the FOSS project run on? - Development environment can be built on Windows, Ubuntu or Mac desktop completely with FOSS software.  (Project development information found [https://mifosforge.jira.com/wiki/display/MIFOS/Workspace+2.0 here])
##Are there resources to support these platforms? - In this example, yes.
##Are students familiar with the platforms? - In this example, yes.
##Result - Score a 2, assumption in this example is students all have newer personal computers and given the ability to set up a development environment on different operating systems that makes the availability of student resources greater.  However, there is some risk because machine requirements for setting up developer environment are not provided and some documentation may be out of date, which provides some risk. 
#Development Features - Is the class dependent on specific development features? (Project development information found [https://mifosforge.jira.com/wiki/display/MIFOS/Workspace+2.0 here])
##Programming language - Is primarily Java.
##Development environment - Can be built on Windows, Ubuntu or Mac completely with FOSS software. 
##Supporting technologies - Suggested IDE is Eclipse, requires Maven, Jetty, and mySQL.
##Result - Need to gauge this on knowledge of students and requirements of class.  Assumption here is students know Java and are familiar with mySQL.  While students are not familiar with Maven and Jetty this may not be necessary for intro bug fix plus the community is very supportive so assistance can be found there.  Given there is some risk, score a 2.


[[Category:Instructor Activities]]
[[Category: Foss2serve]]
[[Category:Learning Activity]]
[[Category: Learning_Activity]]
[[Category:Communication and Tools]]
[[Category:IRC]]
[[Category:CS Principles]]

Revision as of 17:53, 28 February 2013

Project Evaluation

Preparation:

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.
Source
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.
Estimated Time to Completion 60-90 minutes
Learning Objectives Ability to: 1)Utilize the rubric to identify likely HFOSS projects.
Materials/Environment SIGCSE paper Access to Internet/Web and web browser.
Additional Information Lists of projects
Rights Licensed CC BY-SA

Background:

This 8 minute video gives you an overview of rubric and how it is used.

[ Watch the video.]

Directions:

This activity is a walkthrough of evaluating the Mifos project.

Part 1-Evaluate Mission Critical Criteria

Evaluate Viability

  1. Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complex. One heuristic to use is the number of contributors as an indicator project complexity.
    1. Go to Ohloh.net, type Mifos into the Search Projects box, in results click on Mifos to see the Project Summary page
    2. Scroll down to the Community area and calculate the average number of contributors in the last 12 months. The average was 9 so it passed the minimum average number of contributors metric of 6.
    3. 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.
    4. 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.
  2. Activity - To support student participation a project should be reasonably active. Number of committers can be used as an indicator of activity.
    1. Return to the Mifos project summary page in Ohloh. Scroll to the Activity area on the page.
    2. Compute the 12-month average of commits. The 12-month average was about 108, much higher than the minimum average level of commits recommended for activity.
    3. 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 scored a 2 for activity.
  3. Community - A suitable project has an active user community. While it is difficult to quantitatively evaluate the activity of a user community, some indicators include a regular history of project downloads and documentation updates over time, current activity on user mailing lists, and testimonials on the project web site.
    1. Examine download activity
      1. Go to Sourceforge.net and enter Mifos into the search box.
      2. Choose Mifos-Microfinance Open Source from the search results.
      3. Click on the number of downloads that is listed on the project page.
      4. Change the date range to give a graph of downloads over the last year.
    2. Examine mailing list activity.
      1. 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.
      2. Once granted access, examine the Developer mailing list for activity.
    3. Examine the IRC channel
      1. Again from the Contributor tab on the Mifos web page, choose the IRC link.
      2. Examine the IRC channel for activity.
    4. 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.
2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.
3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.
  1. 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.
  2. 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.
  3. Detailed instructions-Instructions are provided in many areas including process, architecture, licensing, product functionality, and developer documentation.
  4. Result-Was scored a 3.

Evaluate Suitability

  1. 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.
    1. 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.
    2. 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.
    3. Result - May score a 1, 2 or 3 depending on the number of bugs suitable for students to tackle and class size.
  2. Contributor Support-Does the project have a high volume of guidance to help students as they learn?
    1. Are communication tools documented?-Communication tools are documented under the Collaboration and Communication section of the Development Tools page which can be accessed from the Contributors tab on the Mifos web site. Instructions on how to access the mailing lists with tips on how to participate are available from the Communications page under the Community tab.
    2. Do developers have a web presence?-Examination of IRC logs shows scattered activity over the last week.
    3. Are operating processed documented?-Links to information about coding standards, code submission process, and commit privileges process can be found on the Tech Overview page accessible from the Contributors tab. The process for making feature requests and for prioritizing feature request is available on the Roadmap page accessible from the Product tab.
    4. Do questions posed have timely and supportive answers?-Responses to user mailing list and developer mailing list over the last month have timely and supportive responses.
    5. Result - Not a lot of activity on IRC, but mailing lists show lots of timely feedback and communication methods and operating procedures are well documented, score a 3.

Part 2-Evaluate Secondary Criteria

Since no mission-critical criteria were scored lower than a 2 the project is then evaluated on secondary criteria. Otherwise, the project would have been considered not suitable for student participation.

Evaluate Viability

  1. Domain
    1. Does this project require domain knowledge that may be difficult for students to learn? - As a domain microfinance students should be able to grasp it well enough to contribute a bug fix, which is the learning objective assumed in this example.
    2. Result - Score a 2 since the domain isn’t as simple to grasp as say a desktop application for word processing or compressing files.
  2. Maturity
    1. To have the organization to support student learning, the project should have at least one stable production release - The roadmap page accessible from product tab on the Mifos web site lists releases.
    2. Result - The Download Mifos page accessible from the Product page says 2.6.0 is the 4th major community-supported release. Scored a 3.
  3. User Support
    1. The project should have clear instructions for downloading, installing, and using the project - There is a demo server, video, and slide presentation that explains system functionality. This information can be found looking at pages listed under the Product tab that can be used to learn about the system. There is also a user manual available from the Support tab. On the Download Mifos page, also listed under the Product tab, there are detailed instructions related to installation, configuration, system requirements, and troubleshooting.
    2. Result - Given the wealth of detailed documentation, score a 3.
  4. Roadmap
    1. Student learning is best supported by projects that have a roadmap that includes new feature development, a method for users to submit new feature requests and a process for identifying how new features are prioritized - The process for making feature requests and for prioritizing feature request is available on the Roadmap page accessible from the Product tab. The Roadmap page has features were implemented in the last release, but no listing for the next release.
    2. Result - Scored a 2 because there is no information listed for feature planning in the next release.

Evaluate Approachability

  1. Contribution Types
    1. Does the project contain opportunities for multiple types of contribution and of the type that fits the class? - There are multiple projects for testers, tech writers, and developers. These can be seen on the Volunteer Projects page.
    2. Result - May be a 1, 2 or 3 depending on whether the number of bugs is suitable for students is enough given the class size.
  2. Openness to Contributions
    1. Acceptance of a student contribution to a project provides valuable affirmation to student learning. Determine whether the project accepts student patches. - The process for contribution is documented.
    2. Result - Score a 3 because the contribution process is documented.
  3. Student Friendliness
    1. Do community members moderate the tone of communication? Review mailing lists and IRC to gauge tone - Review of user mailing list and developer mailing list and IRC logs during evaluation of contributor support showed a positive tone during communication.
    2. Result - Score a 3, no inappropriate or demeaning messages.

Evaluate Suitability

  1. Project Description
    1. Students must be able to understand the purpose of the project. Does the project clearly describe the product? Can students understand the intended uses of the product? - The About tab on the web page lists the vision for the product and how it is used by microfinance institutions.
    2. Result - Score a 3, how the product is used and the vision for it is well documented and should be understandable by students.
  2. Platform
    1. What software and hardware platform does the FOSS project run on? - Development environment can be built on Windows, Ubuntu or Mac desktop completely with FOSS software. (Project development information found here)
    2. Are there resources to support these platforms? - In this example, yes.
    3. Are students familiar with the platforms? - In this example, yes.
    4. Result - Score a 2, assumption in this example is students all have newer personal computers and given the ability to set up a development environment on different operating systems that makes the availability of student resources greater. However, there is some risk because machine requirements for setting up developer environment are not provided and some documentation may be out of date, which provides some risk.
  3. Development Features - Is the class dependent on specific development features? (Project development information found here)
    1. Programming language - Is primarily Java.
    2. Development environment - Can be built on Windows, Ubuntu or Mac completely with FOSS software.
    3. Supporting technologies - Suggested IDE is Eclipse, requires Maven, Jetty, and mySQL.
    4. Result - Need to gauge this on knowledge of students and requirements of class. Assumption here is students know Java and are familiar with mySQL. While students are not familiar with Maven and Jetty this may not be necessary for intro bug fix plus the community is very supportive so assistance can be found there. Given there is some risk, score a 2.
Retrieved from "https://teachingopensource.org/index.php?title=Intro_to_IRC_(Activity)&oldid=4352"
Powered by MediaWiki