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

From TeachingOpenSource
(Difference between pages)
 
 
Line 1: Line 1:
== Project Evaluation ==
__NOTOC__
 
=== Preparation: ===
 
{| 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. 
|'''Title''' || Project Anatomy Activity
|-
|-
|'''Source''' ||
|'''Overview''' || Learners will gain a high level familiarity with the structure, processes, and tools used in FOSS projects.
|-
|-  
|'''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
|-
|'''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
|'''Learning Objectives''' || Upon completion of this activity, a student will be able to: 1) Identify high-level components of and terminology associated with a HFOSS project, 2) Discuss that implementation process and tools can vary from project to project.
|}
|}


=== Background: ===
=== Background: ===
This 8 minute video gives you an overview of rubric and how it is used.
[http://producingoss.com/en/index.html  Producing Open Source Software] by Karl Fogel
 
FOSS projects have a distinct culture and set of tools that support project development. The form of the culture and the specific tools vary somewhat across projects, but there is significant commonality such that many FOSS developers migrate easily among FOSS projects.  


[ Watch the video.]
Now that you have an understanding of some of the communication tools used in FOSS environments, this activity will provide a high-level understanding of some of the culture and development tools that you will use when participating in a FOSS project. The goal of this activity is not to provide depth in any one tool or aspect of culture, but to provide a high-level view of what a typical FOSS project looks like.


=== Directions: ===
=== Directions: ===
This activity is a walkthrough of evaluating the Mifos project.
Read the information below which provides a foundation for understanding a FOSS project. In this section we provide basic definitions for the common aspects of FOSS projects. The Guided Tour will walk you through an HFOSS project and highlight some of the aspects described below. We begin with a discussion of community as FOSS development is as much about community as it is about code.  
====Part 1-Evaluate Mission Critical Criteria====
 
'''Evaluate Viability'''  
'''Community''' - As you have discovered, FOSS projects operate on the basis of a meritocracy where a person defines their position within the community based on the merit of their contributions to a project. These contributions do not necessarily have to be codeAs an individual continues to make valuable contributions, that person will be given (or will take on) additional responsibility.
#Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complexOne heuristic to use is the number of contributors as an indicator project complexity.
 
##Go to Ohloh.net, type Mifos into the Search Projects box, Click on Mifos to see the Project Summary page
There is a typical progression of participants in a FOSS community. Most FOSS developers start as users of the application. They then identify some small change that they want to make and make the change. If the change is accepted, they progress to making a larger change and eventually become responsible for a portion of the project.  
##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.
A committer is a developer who has risen to the level in the meritocracy where that individual is responsible for committing any changes submitted to the code base. This is a large responsibility as the committer must review all changes and make sure that the change is of sufficient quality to be incorporated into the code base.  
##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.
'''Leadership''' -  You may be thinking "But how are decisions made?"  In many FOSS projects, there is a "Benevolent Dictator", AKA "BD". This is the person who has the final say on a decision. And while this person has the final say, they typically rely on one or more developers who have risen in the meritocracy to the point where they have the ability to commit significant changes. As such, the benevolent dictator doesn't actually dictate much, but instead comes to a collaborative agreement with the major developers who have expertise in the area in which the decision must be made. Most BDs actually do not like making decisions by fiat and are reluctant to put their foot down.
#:
 
#Activity - To support student participation a project should be reasonably active. Number of committers can be used as an indicator of activity.
As projects mature, they frequently migrate from a BD model to a democratic model where decisions are made by consensus. A consensus is a decision about an issue that everyone agrees is a reasonable solution. The consensus is usually reached via a discussion about a particular issue and how to solve it. The important thing about consensus organization is that when consensus is reached, it must be posted publicly.
##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.
'''Forking''' - One of the important cultural and technical aspects of a FOSS project is its forkability. Forkability is the ability for anyone to make a copy of the code and start their own project based on that code. That new project is known as a "fork" of the old project. For instance, LibreOffice was forked from OpenOffice. When a project is forked, the source code is copied to a new project and usually some members of the original development team leave the original project and migrate to the new project. Forking is not an ideal situation as it may result from dispute with in the development team that cannot be resolved.
##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.
 
#:
'''Communication''' - FOSS projects use common communication tools. You have already been exposed to wikis and IRC. In addition, most FOSS projects have one or more mailing lists. In addition, bug trackers and version control systems (discussed below) are also frequently used for communication.
#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
'''Roadmaps''' - FOSS projects need some way of defining the future of their project. Most FOSS projects have a Roadmap or Blueprint that does this. The Roadmap may be a detailed schedule of releases with the specific bugs fixed and enhancements added for each release detailed. In smaller projects, the Roadmap may simply be a list of the next enhancements to be added to the project.  
###Go to Sourceforge.net and enter Mifos into the search box. 
 
###Choose Mifos-Microfinance Open Source from the search results.
'''Releases''' - A "release" happens when a project has been developed to the point where the developers want to distribute the code and documentation. Releases are typically planned based on the roadmap for a project. Software development is typically "frozen" at a particular point in time so that testing of the software may proceed before the release. This does not mean that development stops. Version control is used to manage different branches of development that allow some developers to continue to work while others test the code to be released.  
###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.   
Releases are numbered and the convention is to use 1.X for  major releases. Numbering 1.X.x is used for more minor issues. The  next major architectural change would be in 1.2. A complete upgrade of the code (e.g., from python 2 to python 3) would result in an entirely new number, e.g., 2.1.1.
##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.
'''Repositories''' - Most FOSS projects save their code in a repository (AKA repo). A repository is simply a place where software packages are stored and from where they may be retrieved and installed. Some projects use a web-based common repository such as Launchpad, SourceForge, GitHub, or a local repo.  The repo is where users go to download a software application.
###Once granted access, examine the Developer mailing list for activity.
 
##Examine the IRC channel
'''Packaging''' - FOSS projects are distributed as source code. In fact, access to the source code is one of the major benefits of FOSS. The source code should be distributed in a standard format (e.g., tar compressed by gzip for *nix). Additional reading: [http://producingoss.com/en/packaging.html#binary-packages Karl Fogel's section on Binary Packages].
###Again from the Contributor tab on the Mifos web page, choose the IRC link.
 
###Examine the IRC channel for activity.
However, code that is distributed in this manner must be downloaded, unzipped, untarred, and then installed using a manual process. As a result, most FOSS projects create "binary" packages to support easier installation. In this case, "binary" doesn't necessarily mean compiled. It means that the package is pre-configured to be installed on a computer without having to build the project from the source code directly.  
##Result-Downloads appear steady so the project has a community of usersDevelopers are responsive on mailing list and developers have a presence on IRC. Project is scored a 3.
 
'''Upstream/downstream''' - Note that development in a FOSS project is not entirely linear. There are typically many people working on the project simultaneously. The main branch of the project is said to live "upstream" of all efforts to make changes. The upstream version is the main version. Developers "downstream" check out a copy of the code to work on. When a change is made, the change is pushed upstream to the main branch so that everyone is working with a consistent code base.
 
Upstreaming and downstreaming may also refer to the build process where packages are built for release. In addition to upstreaming in an individual project, a project may depend on another project. If project A depends on project B, then the release of the upstream project B must be complete before the release of project A can happen.  
 
'''Version Control''' - Most FOSS projects have multiple people working on the project simultaneously. Developers may even be working on the same area of a project at the same time. A version control system is a system for controlling the revisions made to software. Version control software tracks and controls changes to a project's files. Most FOSS projects use some form of version control to control change in the software. Commonly used version control systems include Git, SVN, CVS, and Mercurial. The version control system provides both a method of communication as well as a way of coordinating changes in the softwareThere is a learning activity later on version control. Additional reading: [http://en.wikipedia.org/wiki/Revision_control Wikipedia page on revision control].
 
'''Trackers''' - In most FOSS projects, there is a need to keep track of all of the bugs found as well as the new enhancements suggested. A bug tracker (AKA issue tracker) is used to track change requests for a project. These change requests could be bug fixes, new feature requests, patches from outside developers, and more. A bug tracker allows issues to be logged, described, prioritized, reproduced, diagnosed, fixed and tested. There is a learning activity later on bug trackers. Additional reading: [http://producingoss.com/en/bug-tracker.html Karl Fogel's section on Bug Trackers].
 
=== Guided Tour: ===
 
'''''The Sugar Labs Project (http://sugarlabs.org/)'''''
 
Read the information found [https://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki here] to get an overview of the goals of the project and the latest news.  
 
'''Contributions --''' Read the [https://wiki.sugarlabs.org/go/Sugar_Labs/Getting_Involved Getting Involved] page which describes the roles of various contributors to SugarLabs. Note that there are a variety of different types of contributions that may be made by people in different rolesSummarize the roles that you think would be most applicable for your students on your faculty wiki page. If you think that more than a single role is applicable, indicate why. What are the commonalities across roles? What are the differences?
 
'''Tracker --''' An overview of the Sugar Labs bug tracker may be found [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems here]. The Sugar Labs bug tracker can be found [http://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&order=priority here]. On your wiki page describe the general process for submitting a bug and indicate the types/categories of tickets listed on this page as well as the information available for each ticket.


'''Evaluate Approachability'''
'''Repository --''' http://git.sugarlabs.org/sugar-base
Scan the "Activities" section on the repository and determine the date of last "Commit" (an update of the repository). Place your answer on your wiki page.


Here you are evaluating a project's on-ramp to contribution, scoring as follows:
'''Release cycle --''' Information about Sugar's release cycle and roadmap can be found [http://wiki.sugarlabs.org/go/Development_Team/Release#Sugar_release_cycle here]. Include an entry on your wiki page that describes how the release cycle and roadmap update are related.


::1-Insufficient-Few or no pointers on how to become involved.
'''Communication --''' Sugar Labs promotes communication among its community members in the following ways.
* IRC: http://meeting.sugarlabs.org/  &  http://chat.sugarlabs.org/
* Mailing lists: http://lists.sugarlabs.org/
* Blog: http://planet.sugarlabs.org/
* Wiki: http://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki


::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.
'''''The Sahana Eden Project (http://eden.sahanafoundation.org/wiki)'''''


#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. 
Read the information found [http://eden.sahanafoundation.org/wiki here] to get an overview of the goals of the project and the types of contributions one can make.
#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 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 -


====Part 2-Evaluate Secondary Criteria====
'''Community --''' In the section titled ''Want to Contribute to Sahana Eden?'', you will find a list of ways in which one can contribute. Again, you will note that there are a variety of distinct groups, each with a distinct responsibility. Follow the links to each of the groups listed below and summarize the information you find there on your faculty wiki page. For example, are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?
Since no mission-critical criteria were scored lower than a 2 the project is evaluated on secondary criteria.
* Developers 
* Testers
* Designers


'''Evaluate Viability'''
'''Tracker --''' The Sahana Eden bug tracker can be found [http://eden.sahanafoundation.org/report here]. Place your answers to the following on your wiki page.
#Domain
* How is the information here different than the information found on the Sugar Labs tracker page?
##Does this project require domain knowledge that may be difficult for students to learn? -
* Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.
##Result -
#Maturity
##To have the organization to support student learning, the project should have at least one stable production release -
##Result -
#User Support
##The project should have clear instructions for downloading, installing, and using the project -
##Result -
#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.
##Result - 


'''Evaluate Approachability'''
'''Repository --''' http://eden.sahanafoundation.org/wiki/InstallationGuidelines
#Contribution Types
The installation guidelines begin [http://eden.sahanafoundation.org/wiki/InstallationGuidelines here] with the option to specify your operating system. For this exercise, choose '''Linux''', then '''Developer''', and finally '''Manually'''. At the bottom on the page click '''InstallationGuidelines/Developer/PostPython'''.
##Does the project contain opportunities for multiple types of contribution and of the type that fits the class?
 
##Result -
'''Release cycle --''' Information about Sahana Eden's release cycle and roadmap can be found [http://eden.sahanafoundation.org/roadmap here]. Include an entry on your wiki page that describes the information you find here.
#Openness to Contributions
 
##Acceptance of a student contribution to a project provides valuable affirmation to student learningDetermine whether the project accepts student patches.
'''Communication --''' Sahana Eden promotes communication among its community members in the following ways.
##Result -
* IRC: http://eden.sahanafoundation.org/wiki/Chat
#Student Friendliness
* Mailing lists: http://wiki.sahanafoundation.org/doku.php/community:mailing_lists#sahana-discuss (wider discussion list for issues relating to the wider Sahana ecosystem)
## Do community members moderate the tone of communicationReview mailing lists and IRC to gauge tone.
* Google Groups: https://groups.google.com/forum/?fromgroups#!forum/sahana-eden
##Result -
 
'''Evaluate Suitability'''
=== Deliverables: ===
#Project Description
 
##Students must be able to understand the purpose of the project.  Does the project clearly describe the product? -
POSSE: Notes on your user wiki page summarizing selected observations made while exploring HFOSS projects.
##Result -
 
#Platform
= Notes for Instructors =
##What software and hardware platform does the FOSS project run on?
The remaining sections of this document are intended for the instructorThey are not part of the learning activity that would be given to students.
##Are there resources to support these platforms?
 
##Are students familiar with the platforms?
=== Assessment: ===
##Result -
How will the activity be graded?
#Development Features - Is the class dependent on specific development features?
   
##Programming language -
How will learning will be measured?
##Development environment -
 
##Supporting technologies -
Include sample assessment questions/rubrics.
##Result -
 
{| border="1" class="wikitable"
! Criteria
! Level 1 (fail)
! Level 2 (pass)
! Level 3 (good)
! Level 4 (exceptional)
|-
| '''The purpose of the project'''
|
|
|
|
 
|-
| '''Why the project is open source'''
|
|
|
|
 
|}
 
=== Comments: ===
What should the instructor know before using this activity?
 
What are some likely difficulties that an instructor may encounter using this activity?
 
=== Variants and Adaptations: ===
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-get-involved.txt Modified version of activity] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].
 
=== Additional Information: ===
{| border="1"
|-  
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]
|-
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf
|-
|'''Level of Difficulty''' || Is this activity easy, medium or challenging?  
|-
|'''Estimated Time to Completion''' ||  60 Minutes
|-
|'''Materials/Environment''' || Access to Internet/Web and web browser.
|-
|'''Author''' || Who wrote this activity?  
|-
|'''Source''' || N/A
|-
|'''License''' || Licensed CC BY-SA
|}
 
=== Suggestions for Open Source Community: ===
Suggestions for an open source community member who is working in conjunction with the instructor.
 
 
--------------------
This work is licensed under a
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]
 
[[File:CC_license.png]]


[[Category: Foss2serve]]
[[Category: Learning_Activity]]
[[Category: Learning_Activity]]
[[Category:Introduction]]
[[Category: CS Principles]]

Revision as of 16:33, 5 February 2017

Title Project Anatomy Activity
Overview Learners will gain a high level familiarity with the structure, processes, and tools used in FOSS projects.
Prerequisite Knowledge None
Learning Objectives Upon completion of this activity, a student will be able to: 1) Identify high-level components of and terminology associated with a HFOSS project, 2) Discuss that implementation process and tools can vary from project to project.


Background:

Producing Open Source Software by Karl Fogel

FOSS projects have a distinct culture and set of tools that support project development. The form of the culture and the specific tools vary somewhat across projects, but there is significant commonality such that many FOSS developers migrate easily among FOSS projects.

Now that you have an understanding of some of the communication tools used in FOSS environments, this activity will provide a high-level understanding of some of the culture and development tools that you will use when participating in a FOSS project. The goal of this activity is not to provide depth in any one tool or aspect of culture, but to provide a high-level view of what a typical FOSS project looks like.

Directions:

Read the information below which provides a foundation for understanding a FOSS project. In this section we provide basic definitions for the common aspects of FOSS projects. The Guided Tour will walk you through an HFOSS project and highlight some of the aspects described below. We begin with a discussion of community as FOSS development is as much about community as it is about code.

Community - As you have discovered, FOSS projects operate on the basis of a meritocracy where a person defines their position within the community based on the merit of their contributions to a project. These contributions do not necessarily have to be code. As an individual continues to make valuable contributions, that person will be given (or will take on) additional responsibility.

There is a typical progression of participants in a FOSS community. Most FOSS developers start as users of the application. They then identify some small change that they want to make and make the change. If the change is accepted, they progress to making a larger change and eventually become responsible for a portion of the project. A committer is a developer who has risen to the level in the meritocracy where that individual is responsible for committing any changes submitted to the code base. This is a large responsibility as the committer must review all changes and make sure that the change is of sufficient quality to be incorporated into the code base.

Leadership - You may be thinking "But how are decisions made?" In many FOSS projects, there is a "Benevolent Dictator", AKA "BD". This is the person who has the final say on a decision. And while this person has the final say, they typically rely on one or more developers who have risen in the meritocracy to the point where they have the ability to commit significant changes. As such, the benevolent dictator doesn't actually dictate much, but instead comes to a collaborative agreement with the major developers who have expertise in the area in which the decision must be made. Most BDs actually do not like making decisions by fiat and are reluctant to put their foot down.

As projects mature, they frequently migrate from a BD model to a democratic model where decisions are made by consensus. A consensus is a decision about an issue that everyone agrees is a reasonable solution. The consensus is usually reached via a discussion about a particular issue and how to solve it. The important thing about consensus organization is that when consensus is reached, it must be posted publicly.

Forking - One of the important cultural and technical aspects of a FOSS project is its forkability. Forkability is the ability for anyone to make a copy of the code and start their own project based on that code. That new project is known as a "fork" of the old project. For instance, LibreOffice was forked from OpenOffice. When a project is forked, the source code is copied to a new project and usually some members of the original development team leave the original project and migrate to the new project. Forking is not an ideal situation as it may result from dispute with in the development team that cannot be resolved.

Communication - FOSS projects use common communication tools. You have already been exposed to wikis and IRC. In addition, most FOSS projects have one or more mailing lists. In addition, bug trackers and version control systems (discussed below) are also frequently used for communication.

Roadmaps - FOSS projects need some way of defining the future of their project. Most FOSS projects have a Roadmap or Blueprint that does this. The Roadmap may be a detailed schedule of releases with the specific bugs fixed and enhancements added for each release detailed. In smaller projects, the Roadmap may simply be a list of the next enhancements to be added to the project.

Releases - A "release" happens when a project has been developed to the point where the developers want to distribute the code and documentation. Releases are typically planned based on the roadmap for a project. Software development is typically "frozen" at a particular point in time so that testing of the software may proceed before the release. This does not mean that development stops. Version control is used to manage different branches of development that allow some developers to continue to work while others test the code to be released.

Releases are numbered and the convention is to use 1.X for major releases. Numbering 1.X.x is used for more minor issues. The next major architectural change would be in 1.2. A complete upgrade of the code (e.g., from python 2 to python 3) would result in an entirely new number, e.g., 2.1.1.

Repositories - Most FOSS projects save their code in a repository (AKA repo). A repository is simply a place where software packages are stored and from where they may be retrieved and installed. Some projects use a web-based common repository such as Launchpad, SourceForge, GitHub, or a local repo. The repo is where users go to download a software application.

Packaging - FOSS projects are distributed as source code. In fact, access to the source code is one of the major benefits of FOSS. The source code should be distributed in a standard format (e.g., tar compressed by gzip for *nix). Additional reading: Karl Fogel's section on Binary Packages.

However, code that is distributed in this manner must be downloaded, unzipped, untarred, and then installed using a manual process. As a result, most FOSS projects create "binary" packages to support easier installation. In this case, "binary" doesn't necessarily mean compiled. It means that the package is pre-configured to be installed on a computer without having to build the project from the source code directly.

Upstream/downstream - Note that development in a FOSS project is not entirely linear. There are typically many people working on the project simultaneously. The main branch of the project is said to live "upstream" of all efforts to make changes. The upstream version is the main version. Developers "downstream" check out a copy of the code to work on. When a change is made, the change is pushed upstream to the main branch so that everyone is working with a consistent code base.

Upstreaming and downstreaming may also refer to the build process where packages are built for release. In addition to upstreaming in an individual project, a project may depend on another project. If project A depends on project B, then the release of the upstream project B must be complete before the release of project A can happen.

Version Control - Most FOSS projects have multiple people working on the project simultaneously. Developers may even be working on the same area of a project at the same time. A version control system is a system for controlling the revisions made to software. Version control software tracks and controls changes to a project's files. Most FOSS projects use some form of version control to control change in the software. Commonly used version control systems include Git, SVN, CVS, and Mercurial. The version control system provides both a method of communication as well as a way of coordinating changes in the software. There is a learning activity later on version control. Additional reading: Wikipedia page on revision control.

Trackers - In most FOSS projects, there is a need to keep track of all of the bugs found as well as the new enhancements suggested. A bug tracker (AKA issue tracker) is used to track change requests for a project. These change requests could be bug fixes, new feature requests, patches from outside developers, and more. A bug tracker allows issues to be logged, described, prioritized, reproduced, diagnosed, fixed and tested. There is a learning activity later on bug trackers. Additional reading: Karl Fogel's section on Bug Trackers.

Guided Tour:

The Sugar Labs Project (http://sugarlabs.org/)

Read the information found here to get an overview of the goals of the project and the latest news.

Contributions -- Read the Getting Involved page which describes the roles of various contributors to SugarLabs. Note that there are a variety of different types of contributions that may be made by people in different roles. Summarize the roles that you think would be most applicable for your students on your faculty wiki page. If you think that more than a single role is applicable, indicate why. What are the commonalities across roles? What are the differences?

Tracker -- An overview of the Sugar Labs bug tracker may be found here. The Sugar Labs bug tracker can be found here. On your wiki page describe the general process for submitting a bug and indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Repository -- http://git.sugarlabs.org/sugar-base Scan the "Activities" section on the repository and determine the date of last "Commit" (an update of the repository). Place your answer on your wiki page.

Release cycle -- Information about Sugar's release cycle and roadmap can be found here. Include an entry on your wiki page that describes how the release cycle and roadmap update are related.

Communication -- Sugar Labs promotes communication among its community members in the following ways.


The Sahana Eden Project (http://eden.sahanafoundation.org/wiki)

Read the information found here to get an overview of the goals of the project and the types of contributions one can make.


Community -- In the section titled Want to Contribute to Sahana Eden?, you will find a list of ways in which one can contribute. Again, you will note that there are a variety of distinct groups, each with a distinct responsibility. Follow the links to each of the groups listed below and summarize the information you find there on your faculty wiki page. For example, are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?

  • Developers
  • Testers
  • Designers

Tracker -- The Sahana Eden bug tracker can be found here. Place your answers to the following on your wiki page.

  • How is the information here different than the information found on the Sugar Labs tracker page?
  • Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Repository -- http://eden.sahanafoundation.org/wiki/InstallationGuidelines The installation guidelines begin here with the option to specify your operating system. For this exercise, choose Linux, then Developer, and finally Manually. At the bottom on the page click InstallationGuidelines/Developer/PostPython.

Release cycle -- Information about Sahana Eden's release cycle and roadmap can be found here. Include an entry on your wiki page that describes the information you find here.

Communication -- Sahana Eden promotes communication among its community members in the following ways.

Deliverables:

POSSE: Notes on your user wiki page summarizing selected observations made while exploring HFOSS projects.

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:

How will the activity be graded?

How will learning will be measured?

Include sample assessment questions/rubrics.

Criteria Level 1 (fail) Level 2 (pass) Level 3 (good) Level 4 (exceptional)
The purpose of the project
Why the project is open source

Comments:

What should the instructor know before using this activity?

What are some likely difficulties that an instructor may encounter using this activity?

Variants and Adaptations:

Modified version of activity used by Chris Murphy in his FOSS Course, UPenn, Murphy.

Additional Information:

ACM Knowledge Area/Knowledge Unit What ACM Computing Curricula 2013 knowledge area and units does this activity cover? ACM_Body_of_Knowledge
ACM Topic What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf
Level of Difficulty Is this activity easy, medium or challenging?
Estimated Time to Completion 60 Minutes
Materials/Environment Access to Internet/Web and web browser.
Author Who wrote this activity?
Source N/A
License Licensed CC BY-SA

Suggestions for Open Source Community:

Suggestions for an open source community member who is working in conjunction with the instructor.



This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

File:CC license.png