http://foss2serve.org/api.php?action=feedcontributions&user=Darci.burdge&feedformat=atomFoss2Serve - User contributions [en]2024-03-28T23:51:05ZUser contributionsMediaWiki 1.18.1http://foss2serve.org/index.php/HumIT_ex2gr3HumIT ex2gr32021-11-13T16:42:43Z<p>Darci.burdge: </p>
<hr />
<div>= Exercise 2 - Group 3 =<br />
<br />
=== Sample learning activities mapped to particular courses ===<br />
<br />
# Select learning activity & map to course<br />
#* Understanding the problem<br />
#** Requirements & Analysis course<br />
#* Installing and running system<br />
#** Intro IT<br />
#* Managing Data<br />
#** Content Management<br />
#* Capturing processes of getting system the run<br />
#** OS Programming (Systems Programming)<br />
#** Some class to help documentation<br />
# Analyze pros and cons<br />
#* Students<br />
#** pros - engaging, motivating, cutting edge<br />
#** cons - complexity, risk & failure<br />
#* Faculty<br />
#** pros - engaging, research potential<br />
#** cons - no existing material, grading, risk & failure<br />
#* Department<br />
#** pros - industry partnership, marketing, grants<br />
#** cons - lack resources, controversy/turf war<br />
#* School<br />
#** pros - pr, industry partnership, alumni industry<br />
#** cons - risk of failure, resource allocation, different mission<br />
#* HFOSS community<br />
#** pros - another valuable project, helping community<br />
#** cons - competition for resources<br />
#* Professional Community and Industry<br />
#** pros - PR opportunity, generate new technology (money)<br />
#** cons - competition<br />
# Identify resources needed<br />
#* Faculty<br />
#** Skilled instructors in courses required<br />
#* Technical Resources<br />
#** Computational needs<br />
#* Administrative<br />
#** Additional technical support<br />
#* Social resources<br />
#** Ties to sign language community<br />
# Identify roadblocks<br />
#* Faculty<br />
#** apathy or antipathy<br />
#* Technical Resources<br />
#** Insufficient resources / lab support<br />
#* Administrative<br />
#** Lack of staff support<br />
#* Social resources<br />
#** Aversion of technology for sign language community<br />
#** Lack of awareness of problem<br />
<br />
[[Category: History]]<br />
[[Category: HumIT]]</div>Darci.burdgehttp://foss2serve.org/index.php/HumIT_exercise2HumIT exercise22021-11-13T16:40:47Z<p>Darci.burdge: </p>
<hr />
<div>= Exercise 2: Evaluate Opportunities for Incorporating HFOSS in your Program =<br />
Goal: The objective of this exercise is to match some of the ideas for learning activities created in exercise 1 with particular courses in your curriculum (or other opportunities outside of class). <br />
<br />
# Select some of the learning activities identified in the first exercise and match them to your program. For each learning activity you should identify a particular course or other opportunity where you could use that activity with students.<br />
# Analyze the pros and cons of using HFOSS for education with respect to the opportunities selected in step 1. For each opportunity, identify the advantages and disadvantages for various stakeholders, starting with the list below. Modify the list of stakeholders as appropriate.<br />
## Students<br />
## Faculty<br />
## Department/college<br />
## Academic institution as a whole<br />
## HFOSS community<br />
## Professional community<br />
## Industry<br />
# Identify the resources that are needed to implement the HFOSS effort(s) examined in the previous step. Below are listed a few categories of resources. What others are there?<br />
## Faculty <br />
## Technical resources<br />
## Administrative<br />
## Social resources (e.g., connections with HFOSS organizations)<br />
# Identify the major roadblocks to implementing the HFOSS effort(s) examined in step 2. Below are a few categories. <br />
## Faculty<br />
## Technical<br />
## Administrative<br />
## Social<br />
# Result: examples of HFOSS opportunities with a discussion of expected pros, cons, needed resources and roadblocks.<br />
# Create a page on the HumIT wiki to capture your group’s results.<br />
<br />
[[Category: History]]<br />
[[Category: HumIT]]</div>Darci.burdgehttp://foss2serve.org/index.php/Evaluation_Table_KeyEvaluation Table Key2021-11-13T16:32:38Z<p>Darci.burdge: </p>
<hr />
<div>This is the key for interpreting the Level values assigned for each evaluation factor. (Reproduced from [[Project_Evaluation_Rubric_(Activity)]])<br />
<br />
* Licensing - Score 2 if the product has a free software or open source software license. Score 0 for other licenses or if the license is missing<br />
* Language - Score 2 if the language is your most preferred choice. Score 1 for less preferred languages or if your preferred language is only a small part of the product. Score 0 if the language is not suitable for your needs<br />
* Level of Activity - Score 2 if you judge all the quarters in the last year as being active. Score 1 if some of the quarters in the last year have been active. Score 0 if there have been no active quarters in the last year.<br />
* Number of Contributors - Score 2 if there are 10 or more contributors. Score 1 if there are 3-10 contributors. Score 0 if there are only 1 or 2 contributors. Note that these numbers are based on the fact that most projects have only 1-2 contributors, and the score assumes you are interested in contributing to a larger, clearly established project. If you would prefer to work with a smaller, less well-established project then adjust your scoring to reflect that.<br />
* Size - Scoring for size depends on your objectives in contributing to a project. A project with little or no code should probably be scored 0. For projects that have an established code base, you might think about whether there is a "sweet spot" for code base size that you think would be ideal for your needs. If you can define that, then score projects in that range as 2. Score projects that are neither 0 or 2 as 1. If you don't know what size would be appropriate, then score anything over a reasonable minimum (suggestion: 10,000 lines) as 1.<br />
* Issue Tracker - Score 2 if issues are being actively added and resolved. Score 0 if there is no issue tracker or no sign of recent activity. Score 1 if there is activity but it is very low or sporadic.<br />
* New Contributor - Score 2 if there are clear instructions and welcome for new contributors (positive answers to at least 3 of the learning activity questions). Score 0 if there is little or no evidence of welcome or instructions for new contributors. Score 1 for anything in between.<br />
* Community Norms - Score 2 if there is a documented and easy to locate statement of community norms that is welcoming and inclusive. Score 0 if there is any evidence of rude, unprofessional, harassing or other undesirable behavior. Score 1 if there are no signs of poor behavior but there is no stated code of conduct.<br />
* User base - Score 2 if there clearly is an active and engaged user base. Score 0 if there is little or no evidence that the product is actually being used by anyone beyond the development team. Score 1 if there is some evidence of use but not much.<br />
<br />
[[Category:Learning Activity]]</div>Darci.burdgehttp://foss2serve.org/index.php/Evaluation_KeyEvaluation Key2021-11-13T16:31:56Z<p>Darci.burdge: </p>
<hr />
<div>This is the key for interpreting the Level values assigned for each evaluation factor. (Reproduced from [[Project_Evaluation_Rubric_(Activity)]])<br />
<br />
* Licensing - Score 2 if the product has a free software or open source software license. Score 0 for other licenses or if the license is missing<br />
* Language - Score 2 if the language is your most preferred choice. Score 1 for less preferred languages or if your preferred language is only a small part of the product. Score 0 if the language is not suitable for your needs<br />
* Level of Activity - Score 2 if you judge all the quarters in the last year as being active. Score 1 if some of the quarters in the last year have been active. Score 0 if there have been no active quarters in the last year.<br />
* Number of Contributors - Score 2 if there are 10 or more contributors. Score 1 if there are 3-10 contributors. Score 0 if there are only 1 or 2 contributors. Note that these numbers are based on the fact that most projects have only 1-2 contributors, and the score assumes you are interested in contributing to a larger, clearly established project. If you would prefer to work with a smaller, less well-established project then adjust your scoring to reflect that.<br />
* Size - Scoring for size depends on your objectives in contributing to a project. A project with little or no code should probably be scored 0. For projects that have an established code base, you might think about whether there is a "sweet spot" for code base size that you think would be ideal for your needs. If you can define that, then score projects in that range as 2. Score projects that are neither 0 or 2 as 1. If you don't know what size would be appropriate, then score anything over a reasonable minimum (suggestion: 10,000 lines) as 1.<br />
* Issue Tracker - Score 2 if issues are being actively added and resolved. Score 0 if there is no issue tracker or no sign of recent activity. Score 1 if there is activity but it is very low or sporadic.<br />
* New Contributor - Score 2 if there are clear instructions and welcome for new contributors (positive answers to at least 3 of the learning activity questions). Score 0 if there is little or no evidence of welcome or instructions for new contributors. Score 1 for anything in between.<br />
* Community Norms - Score 2 if there is a documented and easy to locate statement of community norms that is welcoming and inclusive. Score 0 if there is any evidence of rude, unprofessional, harassing or other undesirable behavior. Score 1 if there are no signs of poor behavior but there is no stated code of conduct.<br />
* User base - Score 2 if there clearly is an active and engaged user base. Score 0 if there is little or no evidence that the product is actually being used by anyone beyond the development team. Score 1 if there is some evidence of use but not much.<br />
<br />
[[Category:Learning Activity]]</div>Darci.burdgehttp://foss2serve.org/index.php/ConferencesConferences2021-11-13T16:30:36Z<p>Darci.burdge: </p>
<hr />
<div>=Conferences=<br />
<br />
The following is a list of conferences that are good places to submit papers, etc. on HFOSS work. The name of the conference and the approx month it is held in are in the heading. The approx month for submission and a link to either the conference or the call for papers page is below each heading.<br />
<br />
===RESPECT W/SIGCSE February=== <br />
Submit papers September<br><br />
[http://respect2018.stcbp.org/call-for-papers/ Conference Website]<br />
<br />
===Frontiers in Education October===<br />
Submit papers February<br><br />
[http://fie2018.org/pages/call-papers Conference Website]<br />
<br />
===SIGITE - October===<br />
Submit papers April<br><br />
[https://sigite2018.sigite.org/authors/call-for-participation/ Conference Website]<br />
<br />
===HICCS January=== <br />
Paper submission begins April<br><br />
[http://hicss.hawaii.edu/ Conference Website]<br />
<br />
===SIGCSE February===<br />
August: Paper Abstracts<br><br />
August end: Full Papers, Panels, Special Sessions, & Workshops<br><br />
October: ACM SRC, BoFs, Demos, Lightning Talks, Posters, Nifty Assignments, & Presymposium Events<br><br />
[https://sigcse2019.sigcse.org/info/cfp.html#papers Conference Website]<br />
<br />
===International Conference on Open Source Systems June===<br />
Full & Short papers: January<br><br />
Workshop, Tutorial Proposals: January<br><br />
Posters & Short Industry Papers: February<br><br />
[https://www.oss2018.org/important-dates/ Conference Website]<br />
<br />
===FIE Frontiers in Education October===<br />
Submit papers May<br><br />
[http://fie2018.org/ Conference Website]<br />
<br />
===Tapia September===<br />
Submit papers March<br><br />
[http://tapiaconference.org/ Conference Website]<br />
<br />
===Grace Hopper Celebration of Women in Technology September=== <br />
[https://ghc.anitab.org/calendar/2018-grace-hopper-celebration/ Conference Website]<br />
<br />
===Annual CCSC Northwestern Regional Conference October===<br />
Submit papers, panels, and tutorials June<br><br />
[http://www.ccsc.org/northwest/2018/index.html Conference Website]<br />
<br />
[[Category: Reference]]</div>Darci.burdgehttp://foss2serve.org/index.php/Community_Perspective_DiscussionCommunity Perspective Discussion2021-11-13T16:25:31Z<p>Darci.burdge: </p>
<hr />
<div>This page provides some "food for thought" questions related to the open source community perspective on attracting and keeping new contributors and making them successful. The goal in posing these questions is to help frame the workshop discussion.<br />
<br />
# How important is it to attract new contributors?<br />
#* What is the motivation for attracting newbies?<br />
#** What is the motivation for attracting students?<br />
#* What percentage of effort is spent on attracting newbies?<br />
#* What is the impact on project future?<br />
# How do projects attract new contributors?<br />
#* What is it about a project that draws new users? Domain? Technology? Community?<br />
#** Does this differ for students?<br />
#* What techniques have been successful for drawing new contributors?<br />
#* What challenges do you face in attracting new contributors?<br />
# What are the onramps for your project?<br />
#* Have you developed learning activities or resources to help in on-ramp?<br />
#** This might be as simple as a brief tour of the project site pointing out features for potential contributors<br />
#* What would be useful as an onramp?<br />
#** Is this something students could build? Bootstrap participation?<br />
# How do projects retain contributors?<br />
#* What techniques have been successful for retaining contributors?<br />
#** Would these need modification for students? <br />
#* How do you guide contributors towards increasing value to the project?<br />
#** How successful have you been with this?<br />
# What skills/knowledge should a potential contributor have?<br />
#* Where do you suggest newbies start?<br />
#* What role do you hope that new contributors play in your project?<br />
#* What is the minimum set of knowledge/skills contributors need to get started?<br />
#** This could be technical or soft skills.<br />
#* What kinds of contributions work best for new contributors?<br />
#* What kinds of contributions are most likely to be accepted by the project?<br />
#* What more advanced knowledge is valuable?<br />
#* How do you convey the need for more advanced knowledge? How do you "grow" newbies?<br />
#* What are the biggest learning curve issues for newbies?<br />
#* Do you use different approaches/techniques for newbies versus people that appear to have some background?<br />
# What advice would you give instructors on how to approach and work with a project?<br />
#* What should instructors do to ensure interactions with students are a positive for the community?<br />
#* What is the right way for instructors to approach a project in order to ensure successful interactions?<br />
#* What should instructors do to ensure successful interactions over time?<br />
#* How can instructors give back to the community?<br />
# How can foss2serve bridge the gap between education and HFOSS projects?<br />
#* How can we make student participation work better for all concerned?<br />
# What else?<br />
#* What other aspects have we not considered?<br />
<br />
[[Category: Events]]</div>Darci.burdgehttp://foss2serve.org/index.php/Academic_Perspective_DiscussionAcademic Perspective Discussion2021-11-13T16:24:44Z<p>Darci.burdge: </p>
<hr />
<div>This page provides some "food for thought" questions related to the academic perspective on student participation in HFOSS projects. The goal in posing these questions is to help frame the workshop discussion.<br />
<br />
# What value do you see in having students participate in HFOSS?<br />
# What approaches have you tried to have students participate in HFOSS?<br />
# What challenges have you encountered in HFOSS efforts?<br />
#* Learning curve for yourself<br />
#* Learning curve for students<br />
#* Curriculum issues<br />
#* Available learning materials<br />
# What has been helpful or difficult about interacting with HFOSS projects?<br />
#* Knowing what tasks to take on<br />
#* Finding the right point of contact<br />
#* Relating term schedules and project schedules<br />
# What advice would you give HFOSS projects about working with students?<br />
# How can foss2serve bridge the gap between education and HFOSS projects?<br />
#* How can we make student participation work better for all concerned?<br />
# What else?<br />
#* What other aspects have we not considered?<br />
<br />
[[Category: Events]]</div>Darci.burdgehttp://foss2serve.org/index.php/Possible_CS1_activitiesPossible CS1 activities2021-11-13T16:16:11Z<p>Darci.burdge: </p>
<hr />
<div>* [http://foss2serve.org/index.php/Document_code_with_meaningful_comments http://foss2serve.org/index.php/Document_code_with_meaningful_comments]<br />
* [http://foss2serve.org/index.php/Intro_Project_Identification_Activity http://foss2serve.org/index.php/Intro_Project_Identification_Activity]<br />
<br />
[[Category:Learning Activity]]</div>Darci.burdgehttp://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity)Project Evaluation Rubric (Activity)2021-11-13T16:13:50Z<p>Darci.burdge: </p>
<hr />
<div><br />
This rubric provides a structure to record results from the [http://foss2serve.org/index.php/Project_Evaluation_(Activity) Project Evaluation Learning Activity]. <br />
<br />
Use: View the source for this page and copy the table below to a new wiki page and then fill in your evaluation. <br />
<br />
'''POSSE participants''': View the source for this page and copy the rubric to your wiki User page and fill it in there.<br />
<br />
=== Rubric instructions ===<br />
<br />
The table below contains entries for each of the evaluation criteria in the [http://foss2serve.org/index.php/Project_Evaluation_(Activity) Project Evaluation Activity]. For each criterion, find the evaluation information needed and record it in the "Evaluation Data" column. Then assign a score in the level column using 0 if the criterion is not met at all, 2 if the criterion is fully met, and 1 if in between.<br />
<br />
;Licensing: Score 2 if the product has a ''free software'' or ''open source software'' license. Score 0 for other licenses or if the license is missing.<br />
;Language: Score 2 if the language is your preferred choice. Score 1 for less preferred languages or if your preferred language is only a small part of the product. Score 0 if the language is not suitable for your needs.<br />
;Level of Activity: Score 2 if all 4 quarters in the last year were active. Score 1 if some quarters were active. Score 0 if no quarters were active.<br />
;Number of Contributors: Score 2 if there are 10 or more contributors. Score 1 if there are 3-10 contributors. Score 0 if there are only 1 or 2 contributors. Most projects have only 1-2 contributors, but the score assumes you want a larger, clearly established project. If you would prefer to work with a smaller, less well-established project then adjust your scoring.<br />
;Project Size: Scoring for size depends on your objectives in contributing to a project. A project with little or no code should probably be scored 0. For projects that have an established code base, you might think about whether there is a "sweet spot" for code base size that you think would be ideal for your needs. If you can define that, then score projects in that range as 2. Score projects that are neither 0 or 2 as 1. If you don't know what size would be appropriate, then score anything over a reasonable minimum (suggestion: 10,000 lines) as 1.<br />
;Issue Tracker: Score 2 if issues are being actively added and resolved. Score 0 if there is no issue tracker or no sign of recent activity. Score 1 if there is activity but it is very low or sporadic.<br />
;New Contributor: Score 2 if there are clear instructions and welcome for new contributors (positive answers to at least 3 of the learning activity questions). Score 0 if there is little or no evidence of welcome or instructions for new contributors. Score 1 for anything in between.<br />
;Community Norms: Score 2 if there is a documented and easy to locate statement of community norms that is welcoming and inclusive. Score 0 if there is any evidence of rude, unprofessional, harassing or other undesirable behavior. Score 1 if there are no signs of poor behavior but no stated code of conduct.<br />
;User Base: Score 2 if there clearly is an active and engaged user base. Score 0 if there is little or no evidence that the product is actually being used by anyone beyond the development team. Score 1 if there is some evidence of use but not much.<br />
<br />
Once you have filled in your evaluation for each of the criteria, total your scores for the project overall.<br />
<br />
<br />
{| class="wikitable" style="width:100%;"<br />
|-<br />
! Evaluation Factor<br />
! Level<br/>(0-2)<br />
! style="width:60%;" | Evaluation Data<br />
|-<br />
| '''Licensing'''<br />
|<br />
|<br />
|-<br />
| '''Language'''<br />
|<br />
|<br />
|-<br />
| '''Level of Activity'''<br />
|<br />
|<br />
|-<br />
| '''Number of Contributors'''<br />
|<br />
|<br />
|-<br />
| '''Product Size'''<br />
|<br />
|<br />
|-<br />
| '''Issue Tracker'''<br />
|<br />
|<br />
|-<br />
| '''New Contributor'''<br />
|<br />
|<br />
|-<br />
| '''Community Norms'''<br />
|<br />
|<br />
|-<br />
| '''User Base'''<br />
|<br />
|<br />
|-<br />
| '''Total Score'''<br />
|<br />
|<br />
|}<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Use and Evaluate]]<br />
[[Category:Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/SIGCSE_2020_POSSE_RoundupSIGCSE 2020 POSSE Roundup2020-03-06T15:57:51Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>__NOTOC__<br />
=== March 11, 2020 - Portland, OR ===<br />
<br />
=== Meeting Location ===<br />
Meeting room: B110, Portland Convention Center.<br />
<br />
The POSSE Roundup is a pre-symposium event for the SIGCSE Symposium. See [https://sigcse2020.sigcse.org/ SIGCSE 2020] for general information about the location.<br />
<br />
=== Overview ===<br />
The workshop will explore HFOSS Kits as an approach to providing more scaffolding and control for faculty taking initial steps to introduce students to HFOSS participation. HFOSS kits will:<br />
<br />
* Provide a controlled, isolated practice environment where students can learn and practice open source skills. A kit contains:<br />
** A project sandbox - copy of an HFOSS project or selected artifacts from a live HFOSS project<br />
** Learning activities for the project sandbox<br />
** Directions and notes for an instructor on how to use the Kit<br />
* Reduce instructor overhead in teaching basic open source skills. Kits will provide a predictable, controlled environment that can be re-set and re-used across multiple academic terms. Kits will also provide an opportunity for students to practice open source tasks repeatedly using real-world artifacts without needing to be concerned about burdening a project community.<br />
* Provide experience with complexity and scale since the artifacts are from real projects. They will not have the benefit of observation and interaction with a project community. <br />
<br />
Kits are intended as a stepping stone to participation in a live HFOSS projects. <br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday March 11, 2020<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome<br />
* Introductions<br />
* Plan for the day<br />
| Heidi, Darci<br />
|-<br />
| 8:45 AM<br />
| Overview - HFOSS and Kits<br />
| Heidi, Stoney <br />
|-<br />
| 9:00 AM<br />
| Breakout: HFOSS Kits<br />
-Intro to HFOSS Activity<br />
<br />
-Advanced HFOSS Activity<br />
| <br />
-Heidi, Lori, Stoney, Greg<br />
<br />
-Karl, Grant, Darci, Chris<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
| Breakout: HFOSS Kits (continued)<br />
| All<br />
|-<br />
| 11:30 AM<br />
| Report from breakout groups<br />
| All<br />
|-<br />
| 12:00 PM<br />
| Lunch (on your own)<br />
| <br />
|-<br />
| 1:30 PM<br />
| Computing for Social Good meeting<br />
| <br />
|-<br />
| 4:45 PM<br />
| Closing remarks<br />
| <br />
|-<br />
| 5:00 PM<br />
| End <br />
| <br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
This POSSE Roundup is open to faculty who are interested in computing for the greater good. Prior open source experience is a plus but not required for the morning part of this meeting. To register, please complete the form <br />
[https://docs.google.com/forms/d/e/1FAIpQLScKZWGyefeWZe5HxHdry9dH_extNgq5GUkJl3oq8UH9k60z5w/viewform?vc=0&c=0&w=1 here].<br />
<br />
NOTE: seating is limited, so please do not assume you are attending before receiving a confirmation from us.<br />
<br />
===== Meeting Minutes =====<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Darci.burdgehttp://foss2serve.org/index.php/SIGCSE_2020_POSSE_RoundupSIGCSE 2020 POSSE Roundup2020-02-23T21:51:36Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>__NOTOC__<br />
=== March 11, 2020 - Portland, OR ===<br />
<br />
=== Meeting Location ===<br />
Meeting room: B110, Portland Convention Center.<br />
<br />
The POSSE Roundup is a pre-symposium event for the SIGCSE Symposium. See [https://sigcse2020.sigcse.org/ SIGCSE 2020] for general information about the location.<br />
<br />
=== Overview ===<br />
The workshop will explore HFOSS Kits as an approach to providing more scaffolding and control for faculty taking initial steps to introduce students to HFOSS participation. HFOSS kits will:<br />
<br />
* Provide a controlled, isolated practice environment where students can learn and practice open source skills. A kit contains:<br />
** A project sandbox - copy of an HFOSS project or selected artifacts from a live HFOSS project<br />
** Learning activities for the project sandbox<br />
** Directions and notes for an instructor on how to use the Kit<br />
* Reduce instructor overhead in teaching basic open source skills. Kits will provide a predictable, controlled environment that can be re-set and re-used across multiple academic terms. Kits will also provide an opportunity for students to practice open source tasks repeatedly using real-world artifacts without needing to be concerned about burdening a project community.<br />
* Provide experience with complexity and scale since the artifacts are from real projects. They will not have the benefit of observation and interaction with a project community. <br />
<br />
Kits are intended as a stepping stone to participation in a live HFOSS projects. <br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday March 11, 2020<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome<br />
* Introductions<br />
* Plan for the day<br />
| Heidi, Darci<br />
|-<br />
| 9:00 AM<br />
| Overview of HFOSS Kits<br />
| Greg, Lori <br />
|-<br />
| 9:30 AM<br />
| Breakout: HFOSS Kits<br />
* Learning outcomes and activities<br />
* Target HFOSS projects <br />
| All<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
| Breakout: HFOSS Kits (continued)<br />
| All<br />
|-<br />
| 11:30 AM<br />
| Report from breakout groups<br />
| All<br />
|-<br />
| 12:00 PM<br />
| Lunch (on your own)<br />
| <br />
|-<br />
| 1:30 PM<br />
| Computing for Social Good meeting<br />
| <br />
|-<br />
| 4:45 PM<br />
| Closing remarks<br />
| <br />
|-<br />
| 5:00 PM<br />
| End <br />
| <br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
This POSSE Roundup is open to faculty who are interested in computing for the greater good. Prior open source experience is a plus but not required for the morning part of this meeting. To register, please complete the form <br />
[https://docs.google.com/forms/d/e/1FAIpQLScKZWGyefeWZe5HxHdry9dH_extNgq5GUkJl3oq8UH9k60z5w/viewform?vc=0&c=0&w=1 here].<br />
<br />
NOTE: seating is limited, so please do not assume you are attending before receiving a confirmation from us.<br />
<br />
===== Meeting Minutes =====<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Darci.burdgehttp://foss2serve.org/index.php/SIGCSE_2020_POSSE_RoundupSIGCSE 2020 POSSE Roundup2020-02-23T21:51:08Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>__NOTOC__<br />
=== March 11, 2020 - Portland, OR ===<br />
<br />
=== Meeting Location ===<br />
Meeting room: B110, Portland Convention Center.<br />
<br />
The POSSE Roundup is a pre-symposium event for the SIGCSE Symposium. See [https://sigcse2020.sigcse.org/ SIGCSE 2020] for general information about the location.<br />
<br />
=== Overview ===<br />
The workshop will explore HFOSS Kits as an approach to providing more scaffolding and control for faculty taking initial steps to introduce students to HFOSS participation. HFOSS kits will:<br />
<br />
* Provide a controlled, isolated practice environment where students can learn and practice open source skills. A kit contains:<br />
** A project sandbox - copy of an HFOSS project or selected artifacts from a live HFOSS project<br />
** Learning activities for the project sandbox<br />
** Directions and notes for an instructor on how to use the Kit<br />
* Reduce instructor overhead in teaching basic open source skills. Kits will provide a predictable, controlled environment that can be re-set and re-used across multiple academic terms. Kits will also provide an opportunity for students to practice open source tasks repeatedly using real-world artifacts without needing to be concerned about burdening a project community.<br />
* Provide experience with complexity and scale since the artifacts are from real projects. They will not have the benefit of observation and interaction with a project community. <br />
<br />
Kits are intended as a stepping stone to participation in a live HFOSS projects. <br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday March 11, 2020<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome<br />
* Introductions<br />
* Plan for the day<br />
| Heidi, Darci<br />
|-<br />
| 9:00 AM<br />
| Overview of HFOSS Kits<br />
| Greg, Lori <br />
|-<br />
| 9:30 AM<br />
| Breakout: HFOSS Kits<br />
* Learning outcomes and activities<br />
* Target HFOSS projects <br />
| All<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
| Breakout: HFOSS Kits (continued)<br />
| All<br />
|-<br />
| 11:30<br />
| Report from breakout groups<br />
| All<br />
|-<br />
| 12:00<br />
| Lunch (on your own)<br />
| <br />
|-<br />
| 1:30 PM<br />
| Computing for Social Good meeting<br />
| <br />
|-<br />
| 4:45 PM<br />
| Closing remarks<br />
| <br />
|-<br />
| 5:00 PM<br />
| End <br />
| <br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
This POSSE Roundup is open to faculty who are interested in computing for the greater good. Prior open source experience is a plus but not required for the morning part of this meeting. To register, please complete the form <br />
[https://docs.google.com/forms/d/e/1FAIpQLScKZWGyefeWZe5HxHdry9dH_extNgq5GUkJl3oq8UH9k60z5w/viewform?vc=0&c=0&w=1 here].<br />
<br />
NOTE: seating is limited, so please do not assume you are attending before receiving a confirmation from us.<br />
<br />
===== Meeting Minutes =====<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_3IRC Meeting 32019-04-14T16:51:27Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== Agenda ==<br />
<br />
'''IRC Meeting 3''' has the following goals:<br />
<br />
* Discuss progress - please continue to log feedback in the [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 activity evaluation spreadsheet]<br />
* Discuss the results of B.4 and C.3 (FOSS in Courses Planning I and II) and answer any questions<br />
** These will be used as a base for [[Stage 2 Activities]] so more detail is better<br />
* Sign up for Stage 2 groups [http://foss2serve.org/index.php/Stage2_Groups here]<br />
** Join one project and one or more courses<br />
* Enter your arrival and departure times in the [https://docs.google.com/spreadsheets/d/1QTaZ0C-rNoDhTiR3wVr5iM7t5SL7lijwhIpGLYsEqaE/edit#gid=0 POSSE Travel Arrangement Google Sheet]<br />
* Please make sure to arrive at Stage 2 with [https://git-scm.com/ Git] installed on your laptop and having completed C.2.<br />
<br />
== To Join ==<br />
<br />
Server: <br />
/attach irc.freenode.net<br />
Channel: <br />
/join #foss2serve<br />
<br />
As with previous IRC meetings, we'll have several of the POSSE team members to facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will get to talk some without the conversation getting too confusing.<br />
<br />
== Notes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage_2_ActivitiesStage 2 Activities2019-04-14T16:50:00Z<p>Darci.burdge: /* Local Information */</p>
<hr />
<div>__NOTOC__<br />
= Local Information =<br />
<br />
Stage 2 will be held at Drexel University, Philadelphia, PA. <br />
<br />
<!--<br />
* '''Meeting location''': The College street address is: 524 West 59th St. New York, NY, 10019, but the best way to enter for POSSE is to use the entrance on 11th Ave. between 58th and 59th streets. <br />
* '''Getting in''': Security will have a list of names for the "POSSE Workshop" and 6.67 as the room. You will need a picture ID to get in.<br />
* '''Meeting room''': Once past security, take the elevator to the 6th floor (Press the button that says 6; ignore the buttons that say L1, L2, etc) We are in room 6.67. The sixth floor has areas for Math and CS, Interdisciplinary studies, and Moot Court. Rooms 6.61 and 6.67 are opposite the glass doors that lead to departments.<br />
* '''Parking''': Parking is available on 11th avenue at the BMW building. There is also parking on 10th avenue at the Mount Sinai garage. 57th street has parking as well. The ParkWhiz App can help find cheap daily rates.<br />
* '''Wednesday Dinner''': We will be having dinner at 5:30 at the Greek Kitchen. Please select your entree from the [[Greek Kitchen Menu]].<br />
--><br />
<br />
= Objectives =<br />
<br />
Participants completing the Stage 2 workshop will be able to:<br />
<br />
* Describe the variety of learning activities that student participation in HFOSS projects may include<br />
* Implement HFOSS activities appropriate for a particular curriculum and student population<br />
* Explain challenges and opportunities of student HFOSS participation<br />
* Discuss key aspects of FOSS culture and process <br />
* Use a selection of tools common in HFOSS projects<br />
* Select an HFOSS project well-suited for student participation<br />
* Identify key sources of information for learning about HFOSS<br />
* Identify other participants with similar ideas about applying HFOSS<br />
* Participate in the TOS community<br />
<br />
== Quick Links == <br />
<!--<br />
*[https://drive.google.com/drive/folders/1NY_P-F9MignULHBMVtTZ03BK8Pnf6qNu Google Drive for Activities]<br />
*[https://pad.riseup.net/p/Intro_A-H Introductions - Last Name A-H]<br />
*[https://pad.riseup.net/p/Intro_I-Z Introductions - Last Name I-Z]<br />
*[https://docs.google.com/document/d/1AX94AXwj-MIOuDGMdQ1ugRmofDlKNJ1FXF8c44OuINI/edit Introductions - if you can't access the Rise-up Pad]<br />
--><br />
<br />
= TENTATIVE Schedule for POSSE 2019-06 in Philadelphia =<br />
<br />
Below is the schedule for the stage 2 workshop activities. <br />
{|border="1"<br />
! Time<br />
! Activity<br />
! Team<br />
|- <br />
|<br />
! Day 1 (Afternoon and Evening)<br />
|<br />
|-<br />
| 1:30 PM<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 2:00 <br />
| 1.1 Welcome<br />
* Plan for the day<br />
* Welcome to Philadelphia<br />
* Introducing everyone<br />
* Workshop overview and schedule<br />
| Greg, Darci<br />
|-<br />
| 2:45<br />
| 1.2 HFOSS in Education - (Activity 75 minutes, Slides 15 minutes)<br />
* 50 Ways to be a FOSSer<br />
* Exploration of student contributions <br />
| Chris, Heidi<br />
|-<br />
| 4:15<br />
| Break<br />
| All<br />
|-<br />
| 4:30<br />
| 1.3 HFOSS Process and Tools<br />
* How tools fit and support HFOSS culture<br />
* Upstream Adoption<br />
* Licensing<br />
| Darci, Heidi<br />
|-<br />
<!--<br />
| 5:00<br />
| GitHub Education<br />
| [http://mozzadrella.me/ Vanessa]<br />
|-<br />
--><br />
| 5:15<br />
| Dinner - working / social dinner<br />
| All<br />
|-<br />
| 6:15<br />
| 1.4 Git Intro Activity<br />
* [https://github.com/StoneyJackson/git-intro-activity Hands-on exploration] of managing a local repository <br />
| Darci, Greg<br />
|-<br />
| 8:00<br />
| Return to the hotel<br />
| All<br />
|-<br />
| 8:30<br />
| Social Hour - Optional<br />
| All<br />
|- <br />
|<br />
! Day 2<br />
|<br />
|- <br />
| 7:45<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:30<br />
| 2.1 Approach to HFOSS Learning<br />
* POGIL<br />
* Pathways<br />
| Greg, Clif<br />
|-<br />
| 9:15<br />
| 2.2 GitHub Workflow Activity<br />
* [https://github.com/StoneyJackson/github-workflow-activity A common workflow] for HFOSS contribution<br />
| Darci, Greg<br />
|-<br />
| <br />
| Take Break When Convenient<br />
| All<br />
|-<br />
| 11:00<br />
| 2.3 Understanding Open Source Communities<br />
* Perspective on basic characteristics common in HFOSS communities<br />
** FOSSisms that capture FOSS culture and methods<br />
| Chris, Clif<br />
|-<br />
<!--<br />
| 12:15<br />
| Mozilla Open Source Student Network<br />
* [https://opensource.mozilla.community/] <br />
| Christos<br />
|-<br />
--><br />
| 12:30<br />
| Lunch <br />
| All<br />
|-<br />
| 1:30<br />
| 2.4 HFOSS in the Curriculum Activity (60 minutes)<br />
* Discussion (15 minutes)<br />
** Options for getting started in courses<br />
** HFOSS beyond the curriculum <br />
** Trying to find the right size student project<br />
** Evaluating student work<br />
** Instructional style: mentoring vs. lecturing; instructor as co-learner<br />
| Heidi, Clif<br />
|-<br />
| 2:30<br />
| 2.5 Project Evaluation Activity<br />
| Darci, Greg<br />
|-<br />
<!--<br />
| 3:15<br />
| Linux Foundation - Open Source Networking<br />
| Trishan<br />
|-<br />
--><br />
| 3:30<br />
| Break<br />
| All<br />
|-<br />
| 3:45<br />
| 2.6 Planning for HFOSS Participation<br />
* Form groups (based either on courses or HFOSS projects)<br />
* In each group:<br />
** Download and install dev environment for HFOSS project if appropriate<br />
** Identify three things that you would like to get done by the end of POSSE<br />
** Plan a schedule for accomplishing these<br />
| Heidi<br />
|-<br />
| 6:00 <br />
| Dinner - Pietro's, 1714 Walnut St.<br />
| All<br />
|- <br />
|<br />
! Day 3<br />
|<br />
|-<br />
| 7:45<br />
| Leave the hotel (checkout first)<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast <br />
| All<br />
|-<br />
| 8:30<br />
| 3.1 Understanding POSSE Stage 3<br />
* Experience reports<br />
** [http://www.seas.upenn.edu/~cdmurphy/foss/Murphy-POSSE-June2018.pptx Chris' slides]<br />
| Greg, [[user:cmurphy | Chris]], Darci<br />
|-<br />
| 9:30 <br />
| <br />
3.2 Sharing HFOSS Learning Activities<br />
* Review of Activity Template<br />
* Group work<br />
| Heidi<br />
|-<br />
| 10:30<br />
| Break<br />
| All<br />
|-<br />
| 10:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* [http://foss2serve.org/index.php/Stage_2_Activities/Stage_3_Planning_-_Format Stage 3 Planning Template]<br />
| All<br />
|-<br />
<!--<br />
| 11:45<br />
| Red Hat University Outreach <br />
| Gina<br />
|---><br />
<br />
| 12:00<br />
| Lunch - Lunch Entertainment: [https://drexel.qualtrics.com/jfe/form/SV_72jbRS6I6TsrIyx Evaluation Form] <br />
| All<br />
|-<br />
| 12:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* Groups report back on work done before lunch<br />
* Groups continue to work <br />
| All<br />
|-<br />
| 1:45 <br />
| 3.3 Stage 3 - First Steps<br />
* What will the group do together?<br />
* Plan some initial activities (faculty only or faculty and students)<br />
* Discuss group communication<br />
* Assessment<br />
| Heidi, Clif<br />
|-<br />
| 2:45<br />
| 3.4 Going Forward<br />
* Evaluation form<br />
* Open discussion <br />
* Closing remarks<br />
| Greg<br />
|-<br />
| 3:30<br />
| End - shuttles and taxi to airport<br />
| All<br />
|}<br />
<br />
= Downloads =<br />
<!-- * [https://drive.google.com/open?id=0B92hZzmXFmvQQlZnZG1EdGhSZEk Presentation Materials - Stage 2 - Day 1] --><br />
<!-- <br />
* [https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8 Presentation materials for stage 2]<br />
* [https://github.com/StoneyJackson/CollabDev Stoney's Git and GitHub Activities]<br />
* [https://docs.google.com/presentation/d/1YYi3STtYoMAfSc59bjz46Sqx4tkYgPhCvDKs5W9Lxew/edit?usp=sharing Matt's presentation] on Mozilla's Campus Clubs<br />
--><br />
<br />
<!-- = Shared Files Folder =<br />
<br />
* [https://drive.google.com/drive/folders/0B2rMbpfK2ojueVE3VmlvUUdCOUE?usp=sharing Google Drive folder for team activities] --><br />
<br />
= IRC =<br />
* Server: '''irc.freenode.net'''<br />
* Channel: '''#foss2serve'''<br />
<br />
Standard IRC clients may not work at some workshop locations due to port blockage. If you have problems, please let the team know and try one of the Web-based IRC interfaces below.<br />
<br />
=== Web-based IRC Clients ===<br />
<br />
* http://webchat.freenode.net/ (has a limit from one IP)<br />
* https://kiwiirc.com/client/irc.freenode.net/ <br />
* http://www.mibbit.com/<br />
<br />
== Logs ==<br />
<!-- <br />
* Thursday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Friday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Saturday:<br />
** Minutes:<br />
** Log:<br />
--><br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-04-14T16:46:31Z<p>Darci.burdge: /* Deliverables */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Bug Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project. <br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Describe the role that a bug tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a bug tracker and their priorities.<br />
# Identify and track the status of a particular bug in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Bug tracking systems are a tool for change management and organization used by FOSS projects. <br />
Bug trackers do far more than simply keep track of bugs. <br />
They also are used to hold new feature requests, patches, and some tasks. <br />
Bug trackers are also called request trackers, issue trackers, and ticket systems. <br />
Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.<br />
<br />
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]<br />
* [http://en.wikipedia.org/wiki/Bug_tracking_system Bug Tracking System (Wikipedia)]<br />
<br />
=== Directions ===<br />
<br />
We will begin by looking at a typical Bugzilla instance for a project. <br />
We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team. <br />
<br />
== Part 1 - Bug Reports ==<br />
# Open a browser and go to the [https://bugzilla.gnome.org/buglist.cgi?type0-7-0=notequals;field0-3-0=product;keywords=accessibility;type0-1-0=notequals;type0-5-0=notequals;keywords_type=allwords;value0-5-0=accerciser;value0-4-0=at-poke;field0-1-0=product;field0-0-0=product;type0-4-0=notequals;field0-6-0=product;value0-3-0=gnome-mag;field0-7-0=product;query_format=advanced;value0-2-0=Dasher;value0-6-0=gnome-speech;value0-1-0=Gok;type0-3-0=notequals;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;field0-2-0=product;field0-5-0=product;field0-4-0=product;type0-6-0=notequals;type0-0-0=notequals;value0-0-0=Orca;type0-2-0=notequals GNOME Accessibility Bugs]<br />
# Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
## ID <br />
## Product <br />
## Comp<br />
## Assignee<br />
## Status <br />
## Resolution <br />
## Summary <br />
# Describe how you discovered the definitions and how you found the information from above (hint: the advanced search shows the options or the Reports link has a link).<br />
# Identify the order in which the bugs are initially displayed.<br />
# What is the meaning of the colors used when describing a bug (red, gray, black)? (Hint: click on the Bug ID and examine the fields)<br />
# Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). <br />
## When was the bug submitted?<br />
## What recent discussion has there been about the bug?<br />
## Is the bug current?<br />
## Is the bug assigned? To whom?<br />
## Describe what you would need to do to fix the bug. <br />
# Repeat the previous step with a different kind of bug.<br />
<br />
== Part 2 - Collective Reports ==<br />
<br />
# Click on the “Reports” link on the top of the page.<br />
# Click on the "Summary of Bug Activity for the last week".<br />
# How many bug reports were opened in the last week? How many were closed? <br />
# What was the general trend last week? Were more bugs opened than closed or vice versa? <br />
# Who were the top three bug closers? Why is this important to know? <br />
# Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? <br />
# Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? <br />
# Click on the "Reports" link at the top of the page and then click on the “Generate Graphical Reports” link.<br />
# Plot a line graph of the severity of bugs by component for Orca:<br />
## Select "Severity" for the vertical axis<br />
## Select "Component" for the horizontal axis<br />
## Select "Bar Graph" for type of graph<br />
## Leave the "Multiple Images" as <none><br />
## Scroll down and select Orca from the Product menu. <br />
## Click "Generate Report". <br />
# What class were the majority of the bugs for braille? <br />
# What other reports can you generate?<br />
<br />
<br />
===Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section describing the results of your exploration.<br />
<br />
= Notes for Instructors =<br />
<br />
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.<br />
<br />
===Assessment: ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
Easy<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Heidi Ellis<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:Bugzilla]]<br />
[[Category:CS Principles]]<br />
[[Category:CS2]]<br />
[[Category: Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T16:00:44Z<p>Darci.burdge: /* Open Food Facts */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
* <name><br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
* <name><br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
* <name><br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
* <name><br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* <name><br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <name><br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T16:00:34Z<p>Darci.burdge: /* Firefox Developer Tools Accessibility */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
* <name><br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
* <name><br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
* <name><br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
* <name><br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
*<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <name><br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T16:00:24Z<p>Darci.burdge: /* Stand-alone HFOSS/Openness */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
* <name><br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
* <name><br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
* <name><br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
*<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
*<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <name><br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T16:00:13Z<p>Darci.burdge: /* Software Engineering/Capstone */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
* <name><br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
* <name><br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
*<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
*<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
*<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <name><br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T16:00:02Z<p>Darci.burdge: /* Introductory Programming II/Data Structures */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
* <name><br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
*<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
*<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
*<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
*<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <name><br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:59:50Z<p>Darci.burdge: /* Ushahidi */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
*<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
*<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
*<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
*<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
*<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <name><br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:59:27Z<p>Darci.burdge: /* Open Food Facts */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
*<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
*<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
*<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
*<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
*<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* Hunter Johnson<br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:59:17Z<p>Darci.burdge: /* Firefox Developer Tools Accessibility */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
*<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
*<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
*<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
*<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Sharon Persinger<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* Hunter Johnson<br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:59:02Z<p>Darci.burdge: /* Stand-alone HFOSS/Openness */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
*<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
*<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
*<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
* Stewart Weiss<br />
* Ying Zhou<br />
* Sarah Zelikovitz<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Sharon Persinger<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* Hunter Johnson<br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:58:52Z<p>Darci.burdge: /* Software Engineering/Capstone */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
*<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
*<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
* Stewart Weiss<br />
* Elin Waring<br />
* Ying Zhou<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
* Stewart Weiss<br />
* Ying Zhou<br />
* Sarah Zelikovitz<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Sharon Persinger<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* Hunter Johnson<br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:58:40Z<p>Darci.burdge: /* Introductory Programming II/Data Structures */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
*<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
* Zhanyang Zhang<br />
* Mira Franke<br />
* Ying Zhou<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
* Stewart Weiss<br />
* Elin Waring<br />
* Ying Zhou<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
* Stewart Weiss<br />
* Ying Zhou<br />
* Sarah Zelikovitz<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Sharon Persinger<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* Hunter Johnson<br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage2_GroupsStage2 Groups2019-04-14T15:58:20Z<p>Darci.burdge: /* Introductory Programming I */</p>
<hr />
<div>__NOTOC__<br />
<br />
='''Instructions:''' =<br />
During POSSE Stage 2, we will do a variety of small group exercises. To help organize the small groups, please sign up for one course and one project by entering your name below. We will organize groups based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Courses ==<br />
We know that undergraduate curriculum structure varies some across institutions, but do what you can to pick from the general course categories below.<br />
<br />
=== Introductory Programming I ===<br />
A first course for computing majors; typically with no computing course pre-requisites<br />
* Heidi Ellis<br />
<br />
=== Introductory Programming II/Data Structures ===<br />
A second course for computing majors<br />
* Stewart Weiss<br />
Susan Imberman<br />
<br />
=== Software Engineering/Capstone ===<br />
An advanced undergraduate course for computing majors; often involves a team project<br />
* Zhanyang Zhang<br />
* Mira Franke<br />
* Ying Zhou<br />
<br />
=== Stand-alone HFOSS/Openness ===<br />
An elective course that might be targeted at computing majors or non-majors; covers broader concepts of open source<br />
* Stewart Weiss<br />
* Elin Waring<br />
* Ying Zhou<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools Accessibility] ===<br />
* Stewart Weiss<br />
* Ying Zhou<br />
* Sarah Zelikovitz<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Sharon Persinger<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* Hunter Johnson<br />
<br />
<!-- The projects below will not be covered in this POSSE --><br />
<!--<br />
=== [http://openmrs.org/ OpenMRS] ===<br />
* <Name><br />
<br />
=== [http://mifos.org/ Mifos] ===<br />
* <Name><br />
<br />
=== [https://sahanafoundation.org/ Sahana] ===<br />
* <name><br />
--><br />
<br />
<br />
[[Category:POSSE]]</div>Darci.burdgehttp://foss2serve.org/index.php/FOSS_in_Courses_1_(Instructors)FOSS in Courses 1 (Instructors)2019-04-14T15:55:00Z<p>Darci.burdge: /* Directions */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS In Courses 1<br />
|overview= <br />
Learners will gain an understanding of the variety of different ways that FOSS can be incorporated into a variety of courses as well as explore different ways to include FOSS into a course of their choosing.<br />
|prerequisites=<br />
An understanding of the course in which students will be involved in a FOSS project.<br />
|objectives=<br />
# List a variety of activities and different ways to contribute to FOSS projects beyond code, <br />
# Identify activities within a FOSS project you are interested in including in a course, <br />
# Identify activities or topics within your course where you think FOSS could fit.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
When many people think about including FOSS in a class, they are typically thinking of one of two things:<br />
# Finding an artifact from the FOSS project such as a code segment that provides the base for study within the classroom (e.g., code review), or <br />
# Making a code contribution to the project by fixing a bug or making an enhancement.<br />
However, there are myriad different activities based on FOSS as well as ways of contributing to FOSS projects that go beyond coding. The purpose of this activity is to explore some of the other ways to introduce students to and/or involve students in FOSS projects.<br />
<br />
Note that the goal of this activity is to get a general idea of appropriate activities and things that you could do in class. It is not expected that you have a complete set of assignments or possibly even one complete assignment by the end of this activity. But by the end you should have an idea of some possibilities of where you could use activities with your course(s). <br />
<br />
=== Directions ===<br />
<br />
# Let's start by observing some of the different activities and ways to contribute. <br />
## Read Andy Lester's [https://smartbear.com/blog/test-and-monitor/14-ways-to-contribute-to-open-source-without-being/ 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star]. Andy does a great job of identifying and ameliorating roadblocks for newbies. <br />
## Read Craig Buchek's [http://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/ great list of ways to contribute other than code]. <br />
## Read through the list of activities on the [[50 Ways to be a FOSSer]] page. <br />
# Rather than reinvent the wheel, lets explore some of the existing materials based on student involvement in FOSS. Read through the following collection of resources.<br />
## This wiki has a set of [[:Category:Learning Activity|Learning Activities]], most of which are introductory. This learning activity itself is part of that set. You'll find it in the [[:Category:POSSE|POSSE]] sub-category. <br />
## TeachingOpenSource has a [http://teachingopensource.org/for-instructors/teaching-materials/ Teaching Materials Catalog] that contains examples of courses and a few individual assignments. <br />
<!--## There is an [http://www.xcitegroup.org/softhum/doku.php?id=f:wnecsefa10 case study] of a software engineering course where students make contributions to HFOSS projects. The course used a series of [http://www.xcitegroup.org/softhum/doku.php?id=f:templates document templates and rubrics]. --><br />
## Seneca College has a [http://zenit.senecac.on.ca/wiki/index.php/Main_Page Center for Open Source Technology] that has links to courses that utilize FOSS.<br />
## Rensselaer Polytechnic Institute also has a [https://rcos.io/ Center for Open Source software].<br />
# Lets turn our attention to your HFOSS project of interest:<br />
## Identify activities or topics that you are interested in within your HFOSS project of interest. This can be a rough list and can serve as the basis for identifying possible class activities/topics.<br />
# Let's turn our attention to your own course. <br />
## Now that you have an idea of the possible types of activities or topics, identify one or two that you think would fit in your class. These do not need to be polished. This can be a rough list of ideas.<br />
## In your reading, did you find existing materials? If so, describe how would you modify them to fit your class? <br />
## If you did not find existing materials, summarize the activity in a sentence or two.<br />
## Post the activity to your wiki page. Note that you may end up identifying more activities than you can use in a single class. Think big!<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: On your foss2serve user wiki page, a section describing the course and identifying one or two possible activities that students can complete as part of the course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. <br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
Access to Internet/Web and web browser.<br />
|author=<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/FOSS_in_Courses_1_(Instructors)FOSS in Courses 1 (Instructors)2019-04-14T15:52:54Z<p>Darci.burdge: /* Directions */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS In Courses 1<br />
|overview= <br />
Learners will gain an understanding of the variety of different ways that FOSS can be incorporated into a variety of courses as well as explore different ways to include FOSS into a course of their choosing.<br />
|prerequisites=<br />
An understanding of the course in which students will be involved in a FOSS project.<br />
|objectives=<br />
# List a variety of activities and different ways to contribute to FOSS projects beyond code, <br />
# Identify activities within a FOSS project you are interested in including in a course, <br />
# Identify activities or topics within your course where you think FOSS could fit.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
When many people think about including FOSS in a class, they are typically thinking of one of two things:<br />
# Finding an artifact from the FOSS project such as a code segment that provides the base for study within the classroom (e.g., code review), or <br />
# Making a code contribution to the project by fixing a bug or making an enhancement.<br />
However, there are myriad different activities based on FOSS as well as ways of contributing to FOSS projects that go beyond coding. The purpose of this activity is to explore some of the other ways to introduce students to and/or involve students in FOSS projects.<br />
<br />
Note that the goal of this activity is to get a general idea of appropriate activities and things that you could do in class. It is not expected that you have a complete set of assignments or possibly even one complete assignment by the end of this activity. But by the end you should have an idea of some possibilities of where you could use activities with your course(s). <br />
<br />
=== Directions ===<br />
<br />
# Let's start by observing some of the different activities and ways to contribute. <br />
## Read Andy Lester's [https://smartbear.com/blog/test-and-monitor/14-ways-to-contribute-to-open-source-without-being/ 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star]. Andy does a great job of identifying and ameliorating roadblocks for newbies. <br />
## Read Craig Buchek's [http://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/ great list of ways to contribute other than code]. <br />
## Read through the list of activities on the [[50 Ways to be a FOSSer]] page. <br />
# Rather than reinvent the wheel, lets explore some of the existing materials based on student involvement in FOSS. Read through the following collection of resources.<br />
## This wiki has a set of [[:Category:Learning Activity|Learning Activities]], most of which are introductory. This learning activity itself is part of that set. You'll find it in the [[:Category:POSSE|POSSE]] sub-category. <br />
## TeachingOpenSource has a [http://teachingopensource.org/for-instructors/teaching-materials/ Teaching Materials Catalog] that contains examples of courses and a few individual assignments. <br />
<!--## There is an [http://www.xcitegroup.org/softhum/doku.php?id=f:wnecsefa10 case study] of a software engineering course where students make contributions to HFOSS projects. The course used a series of [http://www.xcitegroup.org/softhum/doku.php?id=f:templates document templates and rubrics]. --><br />
## Seneca College has a [http://zenit.senecac.on.ca/wiki/index.php/Main_Page Center for Open Source Technology] that has links to courses that utilize FOSS.<br />
## Rensselaer Polytechnic Institute also has a [https://rcos.io/ Center for Open Source Software].<br />
# Lets turn our attention to your HFOSS project of interest:<br />
## Identify activities or topics that you are interested in within your HFOSS project of interest. This can be a rough list and can serve as the basis for identifying possible class activities/topics.<br />
# Let's turn our attention to your own course. <br />
## Now that you have an idea of the possible types of activities or topics, identify one or two that you think would fit in your class. These do not need to be polished. This can be a rough list of ideas.<br />
## In your reading, did you find existing materials? If so, describe how would you modify them to fit your class? <br />
## If you did not find existing materials, summarize the activity in a sentence or two.<br />
## Post the activity to your wiki page. Note that you may end up identifying more activities than you can use in a single class. Think big!<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: On your foss2serve user wiki page, a section describing the course and identifying one or two possible activities that students can complete as part of the course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. <br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
Access to Internet/Web and web browser.<br />
|author=<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/FOSS_in_Courses_1_(Instructors)FOSS in Courses 1 (Instructors)2019-04-14T15:50:49Z<p>Darci.burdge: /* Directions */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS In Courses 1<br />
|overview= <br />
Learners will gain an understanding of the variety of different ways that FOSS can be incorporated into a variety of courses as well as explore different ways to include FOSS into a course of their choosing.<br />
|prerequisites=<br />
An understanding of the course in which students will be involved in a FOSS project.<br />
|objectives=<br />
# List a variety of activities and different ways to contribute to FOSS projects beyond code, <br />
# Identify activities within a FOSS project you are interested in including in a course, <br />
# Identify activities or topics within your course where you think FOSS could fit.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
When many people think about including FOSS in a class, they are typically thinking of one of two things:<br />
# Finding an artifact from the FOSS project such as a code segment that provides the base for study within the classroom (e.g., code review), or <br />
# Making a code contribution to the project by fixing a bug or making an enhancement.<br />
However, there are myriad different activities based on FOSS as well as ways of contributing to FOSS projects that go beyond coding. The purpose of this activity is to explore some of the other ways to introduce students to and/or involve students in FOSS projects.<br />
<br />
Note that the goal of this activity is to get a general idea of appropriate activities and things that you could do in class. It is not expected that you have a complete set of assignments or possibly even one complete assignment by the end of this activity. But by the end you should have an idea of some possibilities of where you could use activities with your course(s). <br />
<br />
=== Directions ===<br />
<br />
# Let's start by observing some of the different activities and ways to contribute. <br />
## Read Andy Lester's [https://smartbear.com/blog/test-and-monitor/14-ways-to-contribute-to-open-source-without-being/ 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star]. Andy does a great job of identifying and ameliorating roadblocks for newbies. <br />
## Read Craig Buchek's [http://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/ great list of ways to contribute other than code]. <br />
## Read through the list of activities on the [[50 Ways to be a FOSSer]] page. <br />
# Rather than reinvent the wheel, lets explore some of the existing materials based on student involvement in FOSS.Read through the following collection of resources.<br />
## This wiki has a set of [[:Category:Learning Activity|Learning Activities]], most of which are introductory. This learning activity itself is part of that set. You'll find it in the [[:Category:POSSE|POSSE]] sub-category. <br />
## TeachingOpenSource has a [http://teachingopensource.org/for-instructors/teaching-materials/ Teaching Materials Catalog] that contains examples of courses and a few individual assignments. <br />
<!--## There is an [http://www.xcitegroup.org/softhum/doku.php?id=f:wnecsefa10 case study] of a software engineering course where students make contributions to HFOSS projects. The course used a series of [http://www.xcitegroup.org/softhum/doku.php?id=f:templates document templates and rubrics]. --><br />
## Seneca College has a [http://zenit.senecac.on.ca/wiki/index.php/Main_Page Center for Open Source Technology] that has links to courses that utilize FOSS.<br />
## Rensselaer Polytechnic Institute also has a [https://rcos.io/ Center for Open Source Software].<br />
# Lets turn our attention to your HFOSS project of interest:<br />
## Identify activities or topics that you are interested in within your HFOSS project of interest. This can be a rough list and can serve as the basis for identifying possible class activities/topics.<br />
# Let's turn our attention to your own course. <br />
## Now that you have an idea of the possible types of activities or topics, identify one or two that you think would fit in your class. These do not need to be polished. This can be a rough list of ideas.<br />
## In your reading, did you find existing materials? If so, describe how would you modify them to fit your class? <br />
## If you did not find existing materials, summarize the activity in a sentence or two.<br />
## Post the activity to your wiki page. Note that you may end up identifying more activities than you can use in a single class. Think big!<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: On your foss2serve user wiki page, a section describing the course and identifying one or two possible activities that students can complete as part of the course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. <br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
Access to Internet/Web and web browser.<br />
|author=<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/Project_Evaluation_(Activity)Project Evaluation (Activity)2019-04-14T15:36:07Z<p>Darci.burdge: /* New contributor */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Project Evaluation<br />
|overview= <br />
This activity guides a person or team to evaluate a FOSS project and decide if they might want to contribute to it.<br />
This includes instructors who want to choose an HFOSS project for a course. <br />
This activity evaluates characteristics that include: <br />
pattern of contributions, pattern of commits, programming languages used, and more. <br />
This activity uses OpenMRS as a sample project to evaluate. <br />
|prerequisites=<br />
* Have Google Chrome installed.<br />
* Understanding of the course or context in which an HFOSS project will be used.<br />
* Completion of [[FOSS Field Trip (Activity)]] or an understanding of GitHub and OpenHub.<br />
|objectives=<br />
* Identify HFOSS projects that seem good for new contributors.<br />
|process skills= Information Processing, Assessment<br />
}}<br />
<br />
=== Background ===<br />
Not all projects are equally good for a new contributor.<br />
Some projects are welcoming and provide clear pathways to join their community.<br />
Other projects are less welcoming, or not well organized to support new people.<br />
Thus, it is helpful to evaluate a project before getting involved and contributing.<br />
This is particularly important when a teacher selects a project for students, <br />
or when students select a project for assignments or a project.<br />
The criteria below provide a framework to consider, but are not foolproof.<br />
<br />
=== Directions ===<br />
=== Walk through of an evaluation of the OpenMRS project ===<br />
<br />
To choose a FOSS project for yourself or your class, it helps to consider multiple criteria, which are explored below.<br />
The [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] <br />
has descriptions and instructions to score each criterion.<br />
Copy the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] onto your wiki page.<br />
Include your findings (notes and the answers to the questions below) in your rubric, along with your scores for each.<br />
<br />
This activity uses OpenMRS as an example to evaluate.<br />
Thus, go to the OpenMRS core repository (https://github.com/openmrs/openmrs-core). <br />
[[File:ProjEval-Img1.jpg|600px|thumb|center]] <br />
<br />
==== Licensing ====<br />
A FOSS license allows anyone to use, change, and redistribute the software. However, there are many FOSS licenses.<br />
The [https://opensource.org Open Source Initiative (OSI)] lists ''open source licenses'' at https://opensource.org/licenses/alphabetical.<br />
The [https://fsf.org Free Software Foundation (FSF)] lists ''free software licenses'' at https://www.gnu.org/licenses/license-list.html.<br />
In general, the OSI definition is broader, and so that list is longer.<br />
# On the repository page (see image above), click on the "<> Code" tab below the repository name. <br />
# Look below the tabs for a license name or a link to the license.<br />
# If the license is not shown, or the project is not on GitHub, look for a license file in the top level files of the repository.<br />
# Does the project use a license approved by the OSI? In the rubric, record your findings. {{Answer|Yes, Mozilla Public 2.0.}}<br />
<br />
==== Language ==== <br />
If you, your team, and your students are already familiar (or expert) with the project's language(s),<br />
it will be much easier to learn how the project works and make contributions.<br />
# On the "<> Code" tab, click on the language details bar (see image above). <br />
# In the rubric, record the top three languages used and the percentages. {{Answer|96% Java, 3% SQL, 1% other (as of 2019-01)}}<br />
<br />
==== Activity ====<br />
A project with little or no activity in the last year might be abandoned and dead,<br />
or it might be stable, mature, and not actively developed.<br />
One measure of activity is the number of ''commits'' (changes) made to the code.<br />
# Click on the "Insights" tab, and then click on "Commits" on the left menu.<br />
# The graph shows the number of commits in each week of the last year. <br />
# Define a quarter (3 months) to be "active" if there were commits in a majority (over half) of the weeks in that quarter. <br />
# Decide (at a glance, no need to count) how many quarters were active, and record in the rubric.<br />
<br />
==== Number of contributors ====<br />
A FOSSism states that "It's all about community" - a healthy project usually has an active user community.<br />
The community is a great resource to help newcomers learn about the project, its culture, and norms. <br />
# Click on the "<> Code" tab. <br />
# The number of contributors is listed above the language details bar. Record this in the rubric.<br />
<br />
==== Size ====<br />
A large project that uses many technologies might overwhelm a CS2 student, but be perfect for a senior capstone course.<br />
A simple measure of size is the lines of code (LoC), and you could do more research to explore complexity. <br />
By default, Github does not show the size or lines of code for a repository. <br />
However, you can install an extension for Google Chrome that will display the size. Follow the instructions below.<br />
# Open Chrome and go to: https://chrome.google.com/webstore/search/github%20repository%20size<br />
# Click the "Add to Chrome" button for the ''GitHub Repository Size'' extension<br />
# Return to the project page in GitHub. You should now see the repository size next to license type. Record the size in the rubric. <br />
<br />
==== Issue tracker ====<br />
An active issue tracker should highlight key issues that clients and developers have raised, and show that they are being addressed.<br />
# Click on the "Issues" tab, which should be next to "<> Code". (Note: If you do not see this tab, then no issues are logged in Github). <br />
#* OpenMRS uses a separate issue tracker.<br />
## Click the link to openmrs.org located near the top of the repository page.<br />
## Scroll to the bottom and click the "OpenMRS Issue Tracking" link.<br />
## Scroll to the table labeled "Two Dimensional Filter Statistics: All JIRA Tickets" located near the bottom of the page.<br />
## Use this to answer the rubric questions below.<br />
# How many ''open'' ("ready for work") issues are there? <br />
# How many ''closed'' issues are there?<br />
# Scroll to the top to see a list of ''Curated Introductory Tickets.'' When was the third issue opened?<br />
# Browse through other issues in the table, and click on some of the cells, to assess whether issues are actively being added and resolved. Record this in the rubric.<br />
<br />
==== New contributor ====<br />
A healthy project should welcome new contributors.<br />
For example, there should be links to "getting started" pages and information on ways to get involved.<br />
These pages, in turn, should have more detail on '''how''' to become involved, and '''how''' to connect with the community.<br />
# Browse the GitHub repository and associated links. Are there signs that the project welcomes new contributors? <br />
# Indicate which of the following are present and include links in the rubric. <br />
#* Note: For OpenMRS you will find two links quite useful: one at the top to openmrs.org and one near the bottom to the OpenMRS wiki.<br />
## Are there instructions to download and install the development environment?<br />
## Are there communication mechanisms, such as IRC, listserves, meeting notices, etc. and instructions on how to access them?<br />
## Is there a discussion platform? If so, are there recent posts and responses?<br />
## Is there Web presence? This might include information about the project, how to get started as a developer, links to blogs, links to IRC logs, links to pages that contain information about coding standards and the code submission process.<br />
# Record your findings in the rubric.<br />
<br />
==== Community norms ==== <br />
How community members interact with one another is important, especially for students.<br />
You do not want to point students to a project that advocates or permits lewd and unprofessional behavior.<br />
# Some projects have a "Code of Conduct", but others do not. Such codes are not in a standard location, so you might find it more quickly with a Google search.<br />
#* For OpenMRS, look in the "Developer Guide" (link along the left side in the OpenMRS wiki) and then choose "Conventions".<br />
# Review some actual interactions for any rude or inappropriate behavior. This could be time consuming since you must first find the type of communication typically used by the community, and then find and review interactions. Choose two topics with at least 5 members and 15 or more replies.<br />
#* For OpenMRS, click the "TALK" link at the top of the OpenMRS wiki page. <br />
# Record the following in the rubric.<br />
## Three observations about the project's Code of Conduct.<br />
## Three observations about communication that occur in the community. Is there any sign of rude or inappropriate behavior?<br />
<br />
==== User base ====<br />
A project will not thrive without a core ''user base'' of clients who use the project on a day-to-day basis.<br />
They give the development team necessary feedback about the project, what works, what doesn't, and what new features they want.<br />
If no one uses the project, then developers are more likely to abandon it. <br />
# Browse the repository and related links, and record your answers to the following in the rubric.<br />
## Does there appear to be a user base?<br />
## Are there instructions for clients to download and set up the software?<br />
## Are there instructions for how to use the software?<br />
<br />
=== Deliverables ===<br />
<br />
POSSE Participants: On your user wiki page, create a section with the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] that describes your evaluation of OpenMRS as a suitable project for your course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor.<br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* For a more introductory class, assessment can be based on simply answering the question included above to evaluate OpenMRS. This generally requires nothing more than being able to point and click and record the correct information. Students will get a simple view of evaluation in one context.<br />
* For more advanced students, possible extensions include:<br />
** Provide the activity as shown above, but have students evaluate another HFOSS project, perhaps one not on GitHub.<br />
** Have students assess (and compare) several HFOSS projects.<br />
** Add assessment questions that require interpretation or comparison of data for various criteria.<br />
** This activity could lead to a larger discussion or reflection about the general problem of product evaluation, selection, and comparison. Those issues are relevant whether the product is FOSS, commercial, or developed in-house.<br />
** This activity could also prompt discussion of measurement problems including qualitative vs. quantitative measures, development of frameworks for evaluation, and weighting of criteria to reach an overall evaluation conclusion<br />
<br />
<!-- QUESTIONS: <br />
Do we need this table, or should we refer to (or insert) the more polished rubric? <br />
Should we create a template for the rubric, so it looks more consistent?<br />
--><br />
The table below provides an outline of a rubric reflecting the recommended evaluation criteria.<br />
<br />
{| class="wikitable" style="width:50%;"<br />
|-<br />
! Evaluation Factor<br />
! Level<br/>(0-2)<br />
! style="width:60%;" | Evaluation Data<br />
|-<br />
| '''Licensing'''<br />
|<br />
|<br />
|-<br />
| '''Language'''<br />
|<br />
|<br />
|-<br />
| '''Level of Activity'''<br />
|<br />
|<br />
|-<br />
| '''Number of Contributors'''<br />
|<br />
|<br />
|-<br />
| '''Product Size'''<br />
|<br />
|<br />
|-<br />
| '''Issue Tracker'''<br />
|<br />
|<br />
|-<br />
| '''New Contributor'''<br />
|<br />
|<br />
|-<br />
| '''Community Norms'''<br />
|<br />
|<br />
|-<br />
| '''User Base'''<br />
|<br />
|<br />
|-<br />
| '''Total Score'''<br />
|<br />
|<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* These criteria are general, but the specific ways to evaluate each one will vary by project and forge. OpenMRS provides a good example for evaluating each criterion for projects on GitHub. Projects on other forges will require different approaches to evaluate many of the criteria.<br />
* FOSS projects tend to have similar structures. If you repeat this evaluation for several projects, it gets easier and quicker, since you know what to look for. (A bit like learning multiple programming languages.)<br />
=== Variants and Adaptations ===<br />
<br />
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt POGIL-style combined FOSS Field Trip and Project Evaluation] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].<br />
<br />
=== Additional Information ===<br />
<br />
* Explore this list of [[HFOSS Projects]] that may be of interest.<br />
* Read the [http://foss2serve.org/images/foss2serve/a/ac/Evaluating_FOSS_Projects.docx SIGCSE paper on evaluating FOSS projects]<br />
* Watch these videos introducing the FOSS project evaluation criteria:<br />
*# [http://youtu.be/MAGet2D5o2c Mission critical criteria]<br />
*# [http://youtu.be/e4lnIXjqczU Secondary criteria]<br />
* Other sources that may help you select a project include:<br />
** [https://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html How to Tell if a FLOSS Project is Doomed to Fail] or a summarized version: [https://opensource.com/life/15/7/why-your-open-source-project-failing Why your open source project is failing]<br />
** [http://producingoss.com/ Producing Open Source Software (2017)] by Karl Fogel is a great reference for many topics. Chapter 2, Getting Started, discusses things a project should address to be successful. That chapter can also be read as a checklist for things a project should have completed if you are considering being a contributor.<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
SE/Software Project Management, SP/Professional Ethics, SP/Intellectual Property, SP/Professional Communication<br />
|acm topic=<br />
* Project Management<br />
* Exposure to the idea that a project has a code of conduct<br />
* Exposure to the idea that licensing of an open source project is essential<br />
* Professional communication and exposure to communication and collaboration tools<br />
|difficulty=<br />
Easy<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
* Access to Internet/Web and web browser<br />
* [[Media:Evaluating_FOSS_Projects.docx | SIGCSE paper on evaluating FOSS projects]]<br />
* [http://www.foss2serve.org/images/foss2serve/0/0c/Blank_Evaluation_Template.xlsx Blank evaluation template referred to in the SIGCSE paper]<br />
|author=<br />
Darci Burdge, Greg Hislop, Michele Purcell<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
None at this time.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Use and Evaluate]]<br />
[[Category:Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/Project_Evaluation_(Activity)Project Evaluation (Activity)2019-04-14T15:33:35Z<p>Darci.burdge: /* Issue tracker */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Project Evaluation<br />
|overview= <br />
This activity guides a person or team to evaluate a FOSS project and decide if they might want to contribute to it.<br />
This includes instructors who want to choose an HFOSS project for a course. <br />
This activity evaluates characteristics that include: <br />
pattern of contributions, pattern of commits, programming languages used, and more. <br />
This activity uses OpenMRS as a sample project to evaluate. <br />
|prerequisites=<br />
* Have Google Chrome installed.<br />
* Understanding of the course or context in which an HFOSS project will be used.<br />
* Completion of [[FOSS Field Trip (Activity)]] or an understanding of GitHub and OpenHub.<br />
|objectives=<br />
* Identify HFOSS projects that seem good for new contributors.<br />
|process skills= Information Processing, Assessment<br />
}}<br />
<br />
=== Background ===<br />
Not all projects are equally good for a new contributor.<br />
Some projects are welcoming and provide clear pathways to join their community.<br />
Other projects are less welcoming, or not well organized to support new people.<br />
Thus, it is helpful to evaluate a project before getting involved and contributing.<br />
This is particularly important when a teacher selects a project for students, <br />
or when students select a project for assignments or a project.<br />
The criteria below provide a framework to consider, but are not foolproof.<br />
<br />
=== Directions ===<br />
=== Walk through of an evaluation of the OpenMRS project ===<br />
<br />
To choose a FOSS project for yourself or your class, it helps to consider multiple criteria, which are explored below.<br />
The [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] <br />
has descriptions and instructions to score each criterion.<br />
Copy the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] onto your wiki page.<br />
Include your findings (notes and the answers to the questions below) in your rubric, along with your scores for each.<br />
<br />
This activity uses OpenMRS as an example to evaluate.<br />
Thus, go to the OpenMRS core repository (https://github.com/openmrs/openmrs-core). <br />
[[File:ProjEval-Img1.jpg|600px|thumb|center]] <br />
<br />
==== Licensing ====<br />
A FOSS license allows anyone to use, change, and redistribute the software. However, there are many FOSS licenses.<br />
The [https://opensource.org Open Source Initiative (OSI)] lists ''open source licenses'' at https://opensource.org/licenses/alphabetical.<br />
The [https://fsf.org Free Software Foundation (FSF)] lists ''free software licenses'' at https://www.gnu.org/licenses/license-list.html.<br />
In general, the OSI definition is broader, and so that list is longer.<br />
# On the repository page (see image above), click on the "<> Code" tab below the repository name. <br />
# Look below the tabs for a license name or a link to the license.<br />
# If the license is not shown, or the project is not on GitHub, look for a license file in the top level files of the repository.<br />
# Does the project use a license approved by the OSI? In the rubric, record your findings. {{Answer|Yes, Mozilla Public 2.0.}}<br />
<br />
==== Language ==== <br />
If you, your team, and your students are already familiar (or expert) with the project's language(s),<br />
it will be much easier to learn how the project works and make contributions.<br />
# On the "<> Code" tab, click on the language details bar (see image above). <br />
# In the rubric, record the top three languages used and the percentages. {{Answer|96% Java, 3% SQL, 1% other (as of 2019-01)}}<br />
<br />
==== Activity ====<br />
A project with little or no activity in the last year might be abandoned and dead,<br />
or it might be stable, mature, and not actively developed.<br />
One measure of activity is the number of ''commits'' (changes) made to the code.<br />
# Click on the "Insights" tab, and then click on "Commits" on the left menu.<br />
# The graph shows the number of commits in each week of the last year. <br />
# Define a quarter (3 months) to be "active" if there were commits in a majority (over half) of the weeks in that quarter. <br />
# Decide (at a glance, no need to count) how many quarters were active, and record in the rubric.<br />
<br />
==== Number of contributors ====<br />
A FOSSism states that "It's all about community" - a healthy project usually has an active user community.<br />
The community is a great resource to help newcomers learn about the project, its culture, and norms. <br />
# Click on the "<> Code" tab. <br />
# The number of contributors is listed above the language details bar. Record this in the rubric.<br />
<br />
==== Size ====<br />
A large project that uses many technologies might overwhelm a CS2 student, but be perfect for a senior capstone course.<br />
A simple measure of size is the lines of code (LoC), and you could do more research to explore complexity. <br />
By default, Github does not show the size or lines of code for a repository. <br />
However, you can install an extension for Google Chrome that will display the size. Follow the instructions below.<br />
# Open Chrome and go to: https://chrome.google.com/webstore/search/github%20repository%20size<br />
# Click the "Add to Chrome" button for the ''GitHub Repository Size'' extension<br />
# Return to the project page in GitHub. You should now see the repository size next to license type. Record the size in the rubric. <br />
<br />
==== Issue tracker ====<br />
An active issue tracker should highlight key issues that clients and developers have raised, and show that they are being addressed.<br />
# Click on the "Issues" tab, which should be next to "<> Code". (Note: If you do not see this tab, then no issues are logged in Github). <br />
#* OpenMRS uses a separate issue tracker.<br />
## Click the link to openmrs.org located near the top of the repository page.<br />
## Scroll to the bottom and click the "OpenMRS Issue Tracking" link.<br />
## Scroll to the table labeled "Two Dimensional Filter Statistics: All JIRA Tickets" located near the bottom of the page.<br />
## Use this to answer the rubric questions below.<br />
# How many ''open'' ("ready for work") issues are there? <br />
# How many ''closed'' issues are there?<br />
# Scroll to the top to see a list of ''Curated Introductory Tickets.'' When was the third issue opened?<br />
# Browse through other issues in the table, and click on some of the cells, to assess whether issues are actively being added and resolved. Record this in the rubric.<br />
<br />
==== New contributor ====<br />
A healthy project should welcome new contributors.<br />
For example, there should be links to "getting started" pages and information on ways to get involved.<br />
These pages, in turn, should have more detail on '''how''' to become involved, and '''how''' to connect with the community.<br />
# Browse the repository and associated links. Are there signs that the project welcomes new contributors? <br />
# Indicate which of the following are present and include links in the rubric. <br />
#* Note: For OpenMRS you will find two links quite useful: one at the top to openmrs.org and one near the bottom to the OpenMRS wiki.<br />
## Are there instructions to download and install the development environment?<br />
## Are there communication mechanisms, such as IRC, listserves, meeting notices, etc. and instructions on how to access them?<br />
## Is there a discussion platform? If so, are there recent posts and responses?<br />
## Is there Web presence? This might include information about the project, how to get started as a developer, links to blogs, links to IRC logs, links to pages that contain information about coding standards and the code submission process.<br />
# Record your findings in the rubric.<br />
<br />
==== Community norms ==== <br />
How community members interact with one another is important, especially for students.<br />
You do not want to point students to a project that advocates or permits lewd and unprofessional behavior.<br />
# Some projects have a "Code of Conduct", but others do not. Such codes are not in a standard location, so you might find it more quickly with a Google search.<br />
#* For OpenMRS, look in the "Developer Guide" (link along the left side in the OpenMRS wiki) and then choose "Conventions".<br />
# Review some actual interactions for any rude or inappropriate behavior. This could be time consuming since you must first find the type of communication typically used by the community, and then find and review interactions. Choose two topics with at least 5 members and 15 or more replies.<br />
#* For OpenMRS, click the "TALK" link at the top of the OpenMRS wiki page. <br />
# Record the following in the rubric.<br />
## Three observations about the project's Code of Conduct.<br />
## Three observations about communication that occur in the community. Is there any sign of rude or inappropriate behavior?<br />
<br />
==== User base ====<br />
A project will not thrive without a core ''user base'' of clients who use the project on a day-to-day basis.<br />
They give the development team necessary feedback about the project, what works, what doesn't, and what new features they want.<br />
If no one uses the project, then developers are more likely to abandon it. <br />
# Browse the repository and related links, and record your answers to the following in the rubric.<br />
## Does there appear to be a user base?<br />
## Are there instructions for clients to download and set up the software?<br />
## Are there instructions for how to use the software?<br />
<br />
=== Deliverables ===<br />
<br />
POSSE Participants: On your user wiki page, create a section with the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] that describes your evaluation of OpenMRS as a suitable project for your course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor.<br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* For a more introductory class, assessment can be based on simply answering the question included above to evaluate OpenMRS. This generally requires nothing more than being able to point and click and record the correct information. Students will get a simple view of evaluation in one context.<br />
* For more advanced students, possible extensions include:<br />
** Provide the activity as shown above, but have students evaluate another HFOSS project, perhaps one not on GitHub.<br />
** Have students assess (and compare) several HFOSS projects.<br />
** Add assessment questions that require interpretation or comparison of data for various criteria.<br />
** This activity could lead to a larger discussion or reflection about the general problem of product evaluation, selection, and comparison. Those issues are relevant whether the product is FOSS, commercial, or developed in-house.<br />
** This activity could also prompt discussion of measurement problems including qualitative vs. quantitative measures, development of frameworks for evaluation, and weighting of criteria to reach an overall evaluation conclusion<br />
<br />
<!-- QUESTIONS: <br />
Do we need this table, or should we refer to (or insert) the more polished rubric? <br />
Should we create a template for the rubric, so it looks more consistent?<br />
--><br />
The table below provides an outline of a rubric reflecting the recommended evaluation criteria.<br />
<br />
{| class="wikitable" style="width:50%;"<br />
|-<br />
! Evaluation Factor<br />
! Level<br/>(0-2)<br />
! style="width:60%;" | Evaluation Data<br />
|-<br />
| '''Licensing'''<br />
|<br />
|<br />
|-<br />
| '''Language'''<br />
|<br />
|<br />
|-<br />
| '''Level of Activity'''<br />
|<br />
|<br />
|-<br />
| '''Number of Contributors'''<br />
|<br />
|<br />
|-<br />
| '''Product Size'''<br />
|<br />
|<br />
|-<br />
| '''Issue Tracker'''<br />
|<br />
|<br />
|-<br />
| '''New Contributor'''<br />
|<br />
|<br />
|-<br />
| '''Community Norms'''<br />
|<br />
|<br />
|-<br />
| '''User Base'''<br />
|<br />
|<br />
|-<br />
| '''Total Score'''<br />
|<br />
|<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* These criteria are general, but the specific ways to evaluate each one will vary by project and forge. OpenMRS provides a good example for evaluating each criterion for projects on GitHub. Projects on other forges will require different approaches to evaluate many of the criteria.<br />
* FOSS projects tend to have similar structures. If you repeat this evaluation for several projects, it gets easier and quicker, since you know what to look for. (A bit like learning multiple programming languages.)<br />
=== Variants and Adaptations ===<br />
<br />
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt POGIL-style combined FOSS Field Trip and Project Evaluation] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].<br />
<br />
=== Additional Information ===<br />
<br />
* Explore this list of [[HFOSS Projects]] that may be of interest.<br />
* Read the [http://foss2serve.org/images/foss2serve/a/ac/Evaluating_FOSS_Projects.docx SIGCSE paper on evaluating FOSS projects]<br />
* Watch these videos introducing the FOSS project evaluation criteria:<br />
*# [http://youtu.be/MAGet2D5o2c Mission critical criteria]<br />
*# [http://youtu.be/e4lnIXjqczU Secondary criteria]<br />
* Other sources that may help you select a project include:<br />
** [https://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html How to Tell if a FLOSS Project is Doomed to Fail] or a summarized version: [https://opensource.com/life/15/7/why-your-open-source-project-failing Why your open source project is failing]<br />
** [http://producingoss.com/ Producing Open Source Software (2017)] by Karl Fogel is a great reference for many topics. Chapter 2, Getting Started, discusses things a project should address to be successful. That chapter can also be read as a checklist for things a project should have completed if you are considering being a contributor.<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
SE/Software Project Management, SP/Professional Ethics, SP/Intellectual Property, SP/Professional Communication<br />
|acm topic=<br />
* Project Management<br />
* Exposure to the idea that a project has a code of conduct<br />
* Exposure to the idea that licensing of an open source project is essential<br />
* Professional communication and exposure to communication and collaboration tools<br />
|difficulty=<br />
Easy<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
* Access to Internet/Web and web browser<br />
* [[Media:Evaluating_FOSS_Projects.docx | SIGCSE paper on evaluating FOSS projects]]<br />
* [http://www.foss2serve.org/images/foss2serve/0/0c/Blank_Evaluation_Template.xlsx Blank evaluation template referred to in the SIGCSE paper]<br />
|author=<br />
Darci Burdge, Greg Hislop, Michele Purcell<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
None at this time.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Use and Evaluate]]<br />
[[Category:Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/Project_Evaluation_(Activity)Project Evaluation (Activity)2019-04-14T15:32:36Z<p>Darci.burdge: /* Issue tracker */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Project Evaluation<br />
|overview= <br />
This activity guides a person or team to evaluate a FOSS project and decide if they might want to contribute to it.<br />
This includes instructors who want to choose an HFOSS project for a course. <br />
This activity evaluates characteristics that include: <br />
pattern of contributions, pattern of commits, programming languages used, and more. <br />
This activity uses OpenMRS as a sample project to evaluate. <br />
|prerequisites=<br />
* Have Google Chrome installed.<br />
* Understanding of the course or context in which an HFOSS project will be used.<br />
* Completion of [[FOSS Field Trip (Activity)]] or an understanding of GitHub and OpenHub.<br />
|objectives=<br />
* Identify HFOSS projects that seem good for new contributors.<br />
|process skills= Information Processing, Assessment<br />
}}<br />
<br />
=== Background ===<br />
Not all projects are equally good for a new contributor.<br />
Some projects are welcoming and provide clear pathways to join their community.<br />
Other projects are less welcoming, or not well organized to support new people.<br />
Thus, it is helpful to evaluate a project before getting involved and contributing.<br />
This is particularly important when a teacher selects a project for students, <br />
or when students select a project for assignments or a project.<br />
The criteria below provide a framework to consider, but are not foolproof.<br />
<br />
=== Directions ===<br />
=== Walk through of an evaluation of the OpenMRS project ===<br />
<br />
To choose a FOSS project for yourself or your class, it helps to consider multiple criteria, which are explored below.<br />
The [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] <br />
has descriptions and instructions to score each criterion.<br />
Copy the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] onto your wiki page.<br />
Include your findings (notes and the answers to the questions below) in your rubric, along with your scores for each.<br />
<br />
This activity uses OpenMRS as an example to evaluate.<br />
Thus, go to the OpenMRS core repository (https://github.com/openmrs/openmrs-core). <br />
[[File:ProjEval-Img1.jpg|600px|thumb|center]] <br />
<br />
==== Licensing ====<br />
A FOSS license allows anyone to use, change, and redistribute the software. However, there are many FOSS licenses.<br />
The [https://opensource.org Open Source Initiative (OSI)] lists ''open source licenses'' at https://opensource.org/licenses/alphabetical.<br />
The [https://fsf.org Free Software Foundation (FSF)] lists ''free software licenses'' at https://www.gnu.org/licenses/license-list.html.<br />
In general, the OSI definition is broader, and so that list is longer.<br />
# On the repository page (see image above), click on the "<> Code" tab below the repository name. <br />
# Look below the tabs for a license name or a link to the license.<br />
# If the license is not shown, or the project is not on GitHub, look for a license file in the top level files of the repository.<br />
# Does the project use a license approved by the OSI? In the rubric, record your findings. {{Answer|Yes, Mozilla Public 2.0.}}<br />
<br />
==== Language ==== <br />
If you, your team, and your students are already familiar (or expert) with the project's language(s),<br />
it will be much easier to learn how the project works and make contributions.<br />
# On the "<> Code" tab, click on the language details bar (see image above). <br />
# In the rubric, record the top three languages used and the percentages. {{Answer|96% Java, 3% SQL, 1% other (as of 2019-01)}}<br />
<br />
==== Activity ====<br />
A project with little or no activity in the last year might be abandoned and dead,<br />
or it might be stable, mature, and not actively developed.<br />
One measure of activity is the number of ''commits'' (changes) made to the code.<br />
# Click on the "Insights" tab, and then click on "Commits" on the left menu.<br />
# The graph shows the number of commits in each week of the last year. <br />
# Define a quarter (3 months) to be "active" if there were commits in a majority (over half) of the weeks in that quarter. <br />
# Decide (at a glance, no need to count) how many quarters were active, and record in the rubric.<br />
<br />
==== Number of contributors ====<br />
A FOSSism states that "It's all about community" - a healthy project usually has an active user community.<br />
The community is a great resource to help newcomers learn about the project, its culture, and norms. <br />
# Click on the "<> Code" tab. <br />
# The number of contributors is listed above the language details bar. Record this in the rubric.<br />
<br />
==== Size ====<br />
A large project that uses many technologies might overwhelm a CS2 student, but be perfect for a senior capstone course.<br />
A simple measure of size is the lines of code (LoC), and you could do more research to explore complexity. <br />
By default, Github does not show the size or lines of code for a repository. <br />
However, you can install an extension for Google Chrome that will display the size. Follow the instructions below.<br />
# Open Chrome and go to: https://chrome.google.com/webstore/search/github%20repository%20size<br />
# Click the "Add to Chrome" button for the ''GitHub Repository Size'' extension<br />
# Return to the project page in GitHub. You should now see the repository size next to license type. Record the size in the rubric. <br />
<br />
==== Issue tracker ====<br />
An active issue tracker should highlight key issues that clients and developers have raised, and show that they are being addressed.<br />
# Click on the "Issues" tab, which should be next to "<> Code". (Note: If you do not see this tab, then no issues are logged in Github). <br />
#* OpenMRS uses a separate issue tracker.<br />
## Click the link to openmrs.org located near the top of the repository page.<br />
## Scroll to the bottom and click the "OpenMRS Issue Tracking" link.<br />
## Scroll to the table labeled "Two Dimensional Filter Statistics: All JIRA Tickets" located near the bottom of the page.<br />
## Use this to answer the rubric questions below.<br />
# How many ''open'' ("ready for work") issues are there? <br />
# How many ''closed'' issues are there?<br />
# Scroll to the top to see a list of ''Curated Introductory Tickets.'' When was the third issue opened?<br />
# Browse the table, and click on some of the cells, to assess whether issues are actively being added and resolved. Record this in the rubric.<br />
<br />
==== New contributor ====<br />
A healthy project should welcome new contributors.<br />
For example, there should be links to "getting started" pages and information on ways to get involved.<br />
These pages, in turn, should have more detail on '''how''' to become involved, and '''how''' to connect with the community.<br />
# Browse the repository and associated links. Are there signs that the project welcomes new contributors? <br />
# Indicate which of the following are present and include links in the rubric. <br />
#* Note: For OpenMRS you will find two links quite useful: one at the top to openmrs.org and one near the bottom to the OpenMRS wiki.<br />
## Are there instructions to download and install the development environment?<br />
## Are there communication mechanisms, such as IRC, listserves, meeting notices, etc. and instructions on how to access them?<br />
## Is there a discussion platform? If so, are there recent posts and responses?<br />
## Is there Web presence? This might include information about the project, how to get started as a developer, links to blogs, links to IRC logs, links to pages that contain information about coding standards and the code submission process.<br />
# Record your findings in the rubric.<br />
<br />
==== Community norms ==== <br />
How community members interact with one another is important, especially for students.<br />
You do not want to point students to a project that advocates or permits lewd and unprofessional behavior.<br />
# Some projects have a "Code of Conduct", but others do not. Such codes are not in a standard location, so you might find it more quickly with a Google search.<br />
#* For OpenMRS, look in the "Developer Guide" (link along the left side in the OpenMRS wiki) and then choose "Conventions".<br />
# Review some actual interactions for any rude or inappropriate behavior. This could be time consuming since you must first find the type of communication typically used by the community, and then find and review interactions. Choose two topics with at least 5 members and 15 or more replies.<br />
#* For OpenMRS, click the "TALK" link at the top of the OpenMRS wiki page. <br />
# Record the following in the rubric.<br />
## Three observations about the project's Code of Conduct.<br />
## Three observations about communication that occur in the community. Is there any sign of rude or inappropriate behavior?<br />
<br />
==== User base ====<br />
A project will not thrive without a core ''user base'' of clients who use the project on a day-to-day basis.<br />
They give the development team necessary feedback about the project, what works, what doesn't, and what new features they want.<br />
If no one uses the project, then developers are more likely to abandon it. <br />
# Browse the repository and related links, and record your answers to the following in the rubric.<br />
## Does there appear to be a user base?<br />
## Are there instructions for clients to download and set up the software?<br />
## Are there instructions for how to use the software?<br />
<br />
=== Deliverables ===<br />
<br />
POSSE Participants: On your user wiki page, create a section with the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] that describes your evaluation of OpenMRS as a suitable project for your course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor.<br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* For a more introductory class, assessment can be based on simply answering the question included above to evaluate OpenMRS. This generally requires nothing more than being able to point and click and record the correct information. Students will get a simple view of evaluation in one context.<br />
* For more advanced students, possible extensions include:<br />
** Provide the activity as shown above, but have students evaluate another HFOSS project, perhaps one not on GitHub.<br />
** Have students assess (and compare) several HFOSS projects.<br />
** Add assessment questions that require interpretation or comparison of data for various criteria.<br />
** This activity could lead to a larger discussion or reflection about the general problem of product evaluation, selection, and comparison. Those issues are relevant whether the product is FOSS, commercial, or developed in-house.<br />
** This activity could also prompt discussion of measurement problems including qualitative vs. quantitative measures, development of frameworks for evaluation, and weighting of criteria to reach an overall evaluation conclusion<br />
<br />
<!-- QUESTIONS: <br />
Do we need this table, or should we refer to (or insert) the more polished rubric? <br />
Should we create a template for the rubric, so it looks more consistent?<br />
--><br />
The table below provides an outline of a rubric reflecting the recommended evaluation criteria.<br />
<br />
{| class="wikitable" style="width:50%;"<br />
|-<br />
! Evaluation Factor<br />
! Level<br/>(0-2)<br />
! style="width:60%;" | Evaluation Data<br />
|-<br />
| '''Licensing'''<br />
|<br />
|<br />
|-<br />
| '''Language'''<br />
|<br />
|<br />
|-<br />
| '''Level of Activity'''<br />
|<br />
|<br />
|-<br />
| '''Number of Contributors'''<br />
|<br />
|<br />
|-<br />
| '''Product Size'''<br />
|<br />
|<br />
|-<br />
| '''Issue Tracker'''<br />
|<br />
|<br />
|-<br />
| '''New Contributor'''<br />
|<br />
|<br />
|-<br />
| '''Community Norms'''<br />
|<br />
|<br />
|-<br />
| '''User Base'''<br />
|<br />
|<br />
|-<br />
| '''Total Score'''<br />
|<br />
|<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* These criteria are general, but the specific ways to evaluate each one will vary by project and forge. OpenMRS provides a good example for evaluating each criterion for projects on GitHub. Projects on other forges will require different approaches to evaluate many of the criteria.<br />
* FOSS projects tend to have similar structures. If you repeat this evaluation for several projects, it gets easier and quicker, since you know what to look for. (A bit like learning multiple programming languages.)<br />
=== Variants and Adaptations ===<br />
<br />
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt POGIL-style combined FOSS Field Trip and Project Evaluation] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].<br />
<br />
=== Additional Information ===<br />
<br />
* Explore this list of [[HFOSS Projects]] that may be of interest.<br />
* Read the [http://foss2serve.org/images/foss2serve/a/ac/Evaluating_FOSS_Projects.docx SIGCSE paper on evaluating FOSS projects]<br />
* Watch these videos introducing the FOSS project evaluation criteria:<br />
*# [http://youtu.be/MAGet2D5o2c Mission critical criteria]<br />
*# [http://youtu.be/e4lnIXjqczU Secondary criteria]<br />
* Other sources that may help you select a project include:<br />
** [https://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html How to Tell if a FLOSS Project is Doomed to Fail] or a summarized version: [https://opensource.com/life/15/7/why-your-open-source-project-failing Why your open source project is failing]<br />
** [http://producingoss.com/ Producing Open Source Software (2017)] by Karl Fogel is a great reference for many topics. Chapter 2, Getting Started, discusses things a project should address to be successful. That chapter can also be read as a checklist for things a project should have completed if you are considering being a contributor.<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
SE/Software Project Management, SP/Professional Ethics, SP/Intellectual Property, SP/Professional Communication<br />
|acm topic=<br />
* Project Management<br />
* Exposure to the idea that a project has a code of conduct<br />
* Exposure to the idea that licensing of an open source project is essential<br />
* Professional communication and exposure to communication and collaboration tools<br />
|difficulty=<br />
Easy<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
* Access to Internet/Web and web browser<br />
* [[Media:Evaluating_FOSS_Projects.docx | SIGCSE paper on evaluating FOSS projects]]<br />
* [http://www.foss2serve.org/images/foss2serve/0/0c/Blank_Evaluation_Template.xlsx Blank evaluation template referred to in the SIGCSE paper]<br />
|author=<br />
Darci Burdge, Greg Hislop, Michele Purcell<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
None at this time.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Use and Evaluate]]<br />
[[Category:Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/FOSS_Field_Trip_(Activity)FOSS Field Trip (Activity)2019-04-14T15:07:24Z<p>Darci.burdge: /* Part 2 - OpenHub */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS Field Trip - Browsing for FOSS Projects<br />
|overview= <br />
Learners will explore the breadth of available FOSS projects as well as differences between GitHub and OpenHub.<br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Search for FOSS projects on both GitHub and OpenHub.<br />
# Use and describe different features of GitHub and OpenHub.<br />
|process skills=<br />
# Critical Thinking<br />
# Information Processing<br />
}}<br />
<br />
=== Background ===<br />
<br />
FOSS predates the web, but the web is now essential for most FOSS projects.<br />
People locate and access FOSS projects on the web, and FOSS communities collaborate on the web.<br />
A FOSS project has a set of files (including source code, documentation, etc), usually organized into folders.<br />
Most FOSS projects keep the complete history of every file, to know what changes were made, by who, and when.<br />
The set of files and their history is a '''repository''', or a '''repo''' for short.<br />
<br />
Most FOSS projects also use web-based collaborative tools to develop and share code and documentation, <br />
track who does what, and discuss questions, problems, and suggestions.<br />
A software platform with these tools is a '''forge'''.<br />
Some forges support ''one'' FOSS project (usually a ''large'' project),<br />
and other forges host ''many'' independent FOSS projects.<br />
Well known forges include [https://github.com GitHub], [https://sourceforge.net SourceForge], and [https://bitbucket.org Bitbucket].<br />
Note that the software used by such sites is also called a '''forge''';<br />
for example, [https://gitlab.com GitLab], [https://redmine.org RedMine], and [https://trac.edgewall.org Trac]<br />
are FOSS forges that anyone can install and modify, unlike [https://github.com GitHub].<br />
<br />
This activity also uses '''OpenHub''' (formerly '''Ohloh'''), <br />
which is ''not'' a forge, but mines data from forges to analyze project activity.<br />
<br />
=== Directions ===<br />
<br />
* ''POSSE Attendees'': Post your answers on your foss2serve wiki page.<br />
* ''Students'': Ask your instructor how to report your answers.<br />
<br />
==== Part 1 - GitHub ====<br />
<br />
In Part 1 you will search '''GitHub''' for projects. Do the following:<br />
# Open a new browser tab and go to: https://github.com<br />
# Find the search box near the top of the page, type "education", and press enter or click on the search icon.<br />
## How many ''repositories'' are found for "education"? {{Answer|~25,000 (as of 2019-01)}}<br />
## How many of these repos use the JavaScript language? (Hint: Find a summary table.) {{Answer|~3000 (as of 2019-01)}}<br />
## In the first page of results, which repo was updated ''most'' recently? Which was updated ''least'' recently? {{Answer|Answers will vary, and may range from a few hours ago to several years ago.}}<br />
# Many repos are small and inactive. To see the most active repos, find ''Sort'' and pick ''most stars''. <br />
## Which ''education'' repo has the most stars? How many? {{Answer|freeCodeCamp with ~300k (as of 2019-01)}}<br />
# Click on this repo to see its overview page. Scroll down past the list of files to see a project description.<br />
# In GitHub, each reported problem or suggestion is an '''issue''', the code and documentation to fix an issue is a '''pull request''', and a pull request that is accepted and added to a repo is a '''commit'''. Each issue and pull request is either ''open'' (in progress) or ''closed'' (done). (You will learn more about all of this later.)<br />
## At the top of the overview page, click on the ''Issues'' tab. You should see a list. How many issues are ''open''? ''closed''? {{Answer|~350 and ~13k for freeCodeCamp (as of 2019-01)}}<br />
## Click on the ''Pull requests'' tab. You should see a list. How many pull requests are ''open''? ''closed''? {{Answer|~5000 and ~16k for freeCodeCamp (as of 2019-01)}}<br />
## Click on the ''Insights'' tab. What do you see? {{Answer|Bargraphs of issues, pull requests, and commits this week.}}<br />
## Within ''Insights'', go to the left menu and click on ''Commits''. What do you see? {{Answer|A bargraph showing the number of commits each week for the last year.}}<br />
# Go back to the main GitHub page.<br />
## Search for "humanitarian" projects. How many repos are found? {{Answer|~350 (as of 2019-01)}}<br />
## Find ''HTBox/crisischeckin''. How many stars does it have? What language(s) does it use? When was the last update? {{Answer|~200 stars, C#, date will vary (as of 2019-01)}}<br />
## Search for "disaster management", or terms that interest you. How many repos are found? {{Answer|Varies}}<br />
<br />
Keep the GitHub browser tab open as you move on to Part 2.<br />
<br />
==== Part 2 - OpenHub ====<br />
<br />
In Part 2, you will search '''OpenHub''' for projects. Do the following:<br />
# Open a new browser tab and go to: https://www.openhub.net<br />
# In the search box, type "education".<br />
## The listing shows the number of ''pages'', not the number of ''projects''. By default, each page shows 10 projects. How many ''projects'' were found? {{Answer|~230 pages -> ~2300 projects (as of 2019-01)}}<br />
# Many projects are small and inactive. To see the most active projects, find ''Sort by'' and pick ''Activity Level''.<br />
## Which (if any) of the most active projects do you recognize? {{Answer|Varies, maybe Moodle, Sakai, DSpace.}}<br />
# In the ''Sort by'' text box pick ''Relevance''. If necessary, go to the bottom of the screen and advance to pages 2, 3, ... in the listing until you find ''KDE Education'', and click on it.<br />
## From the ''KDE Education'' page, click on ''Code Locations'' (on the right side). Are any of the repo locations on GitHub? {{Answer|No, all are on kde.org (as of 2019-01)}}<br />
## Go back to ''KDE Education'', and click on ''Similar Projects'' (below ''Code Locations''). How many similar projects are listed? {{Answer|~10 (as of 2019-01)}}<br />
## This page contains general information for the similar projects. What info is shown for each? {{Answer|name, activity level, language, license (as of 2019-01)}}<br />
# Repeat your OpenHub search for both "humanitarian" and "disaster management", or terms that interest you.<br />
## How many projects did each search return? {{Answer|Varies. ~30 for humanitarian, ~30 for disaster mgmt (as of 2019-01)}}<br />
# Some projects show "Activity Not Available". Click on the pyramid icon and read the page shown. Why is "activity not available"? {{Answer|OpenHub could not access or analysis project data.}}<br />
# Click on ''Organizations'' (near the top of the main OpenHub page).<br />
## What info is shown? {{Answer|Most active orgs, newest orgs, stats by sector, etc (as of 2019-01)}}<br />
# From ''Organizations'', search for "OpenMRS".<br />
## Do the search results show projects or organizations? {{Answer|Organizations}} <br />
## Find the project "OpenMRS Core". When was the last commit? {{Answer|Varies. 11 months ago (as of 2019-01)}}<br />
# Go back to '''GitHub''' and search for the project "OpenMRS Core". When was the last commit? {{Answer|Varies. 4 days ago (as of 2019-01)}}<br />
## Why do you think these sites have different info? {{Answer|OpenHub might be looking in the wrong place, or misreading data.}}<br />
# What are some benefits & drawbacks of searching for a project in both GitHub & OpenHub? {{Answer|???}}<br />
<br />
=== Deliverables ===<br />
<br />
* ''POSSE Attendees'': Please post the answers to these questions on your foss2serve user wiki page.<br />
* ''Students'': Wiki posting describing your explorations of GitHub and OpenHub.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor.<br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor might encounter using this activity?<br />
<br />
=== Variants and Adaptations: ===<br />
<br />
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt POGIL-style combined FOSS Field Trip and Project Evaluation] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
30-60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser.<br />
|author=<br />
|source=<br />
[http://www.xcitegroup.org/softhum/doku.php?id=f:assignment_ossfieldtrip1detail Detailed FOSS Field Trip]<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Introduction]]<br />
[[Category:CS Principles]]<br />
[[Category:CS1]]<br />
[[Category: Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/FOSS_Field_Trip_(Activity)FOSS Field Trip (Activity)2019-04-14T15:06:33Z<p>Darci.burdge: /* Part 2 - OpenHub */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS Field Trip - Browsing for FOSS Projects<br />
|overview= <br />
Learners will explore the breadth of available FOSS projects as well as differences between GitHub and OpenHub.<br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Search for FOSS projects on both GitHub and OpenHub.<br />
# Use and describe different features of GitHub and OpenHub.<br />
|process skills=<br />
# Critical Thinking<br />
# Information Processing<br />
}}<br />
<br />
=== Background ===<br />
<br />
FOSS predates the web, but the web is now essential for most FOSS projects.<br />
People locate and access FOSS projects on the web, and FOSS communities collaborate on the web.<br />
A FOSS project has a set of files (including source code, documentation, etc), usually organized into folders.<br />
Most FOSS projects keep the complete history of every file, to know what changes were made, by who, and when.<br />
The set of files and their history is a '''repository''', or a '''repo''' for short.<br />
<br />
Most FOSS projects also use web-based collaborative tools to develop and share code and documentation, <br />
track who does what, and discuss questions, problems, and suggestions.<br />
A software platform with these tools is a '''forge'''.<br />
Some forges support ''one'' FOSS project (usually a ''large'' project),<br />
and other forges host ''many'' independent FOSS projects.<br />
Well known forges include [https://github.com GitHub], [https://sourceforge.net SourceForge], and [https://bitbucket.org Bitbucket].<br />
Note that the software used by such sites is also called a '''forge''';<br />
for example, [https://gitlab.com GitLab], [https://redmine.org RedMine], and [https://trac.edgewall.org Trac]<br />
are FOSS forges that anyone can install and modify, unlike [https://github.com GitHub].<br />
<br />
This activity also uses '''OpenHub''' (formerly '''Ohloh'''), <br />
which is ''not'' a forge, but mines data from forges to analyze project activity.<br />
<br />
=== Directions ===<br />
<br />
* ''POSSE Attendees'': Post your answers on your foss2serve wiki page.<br />
* ''Students'': Ask your instructor how to report your answers.<br />
<br />
==== Part 1 - GitHub ====<br />
<br />
In Part 1 you will search '''GitHub''' for projects. Do the following:<br />
# Open a new browser tab and go to: https://github.com<br />
# Find the search box near the top of the page, type "education", and press enter or click on the search icon.<br />
## How many ''repositories'' are found for "education"? {{Answer|~25,000 (as of 2019-01)}}<br />
## How many of these repos use the JavaScript language? (Hint: Find a summary table.) {{Answer|~3000 (as of 2019-01)}}<br />
## In the first page of results, which repo was updated ''most'' recently? Which was updated ''least'' recently? {{Answer|Answers will vary, and may range from a few hours ago to several years ago.}}<br />
# Many repos are small and inactive. To see the most active repos, find ''Sort'' and pick ''most stars''. <br />
## Which ''education'' repo has the most stars? How many? {{Answer|freeCodeCamp with ~300k (as of 2019-01)}}<br />
# Click on this repo to see its overview page. Scroll down past the list of files to see a project description.<br />
# In GitHub, each reported problem or suggestion is an '''issue''', the code and documentation to fix an issue is a '''pull request''', and a pull request that is accepted and added to a repo is a '''commit'''. Each issue and pull request is either ''open'' (in progress) or ''closed'' (done). (You will learn more about all of this later.)<br />
## At the top of the overview page, click on the ''Issues'' tab. You should see a list. How many issues are ''open''? ''closed''? {{Answer|~350 and ~13k for freeCodeCamp (as of 2019-01)}}<br />
## Click on the ''Pull requests'' tab. You should see a list. How many pull requests are ''open''? ''closed''? {{Answer|~5000 and ~16k for freeCodeCamp (as of 2019-01)}}<br />
## Click on the ''Insights'' tab. What do you see? {{Answer|Bargraphs of issues, pull requests, and commits this week.}}<br />
## Within ''Insights'', go to the left menu and click on ''Commits''. What do you see? {{Answer|A bargraph showing the number of commits each week for the last year.}}<br />
# Go back to the main GitHub page.<br />
## Search for "humanitarian" projects. How many repos are found? {{Answer|~350 (as of 2019-01)}}<br />
## Find ''HTBox/crisischeckin''. How many stars does it have? What language(s) does it use? When was the last update? {{Answer|~200 stars, C#, date will vary (as of 2019-01)}}<br />
## Search for "disaster management", or terms that interest you. How many repos are found? {{Answer|Varies}}<br />
<br />
Keep the GitHub browser tab open as you move on to Part 2.<br />
<br />
==== Part 2 - OpenHub ====<br />
<br />
In Part 2, you will search '''OpenHub''' for projects. Do the following:<br />
# Open a new browser tab and go to: https://www.openhub.net<br />
# In the search box, type "education".<br />
## The listing shows the number of ''pages'', not the number of ''projects''. By default, each page shows 10 projects. How many ''projects'' were found? {{Answer|~230 pages -> ~2300 projects (as of 2019-01)}}<br />
# Many projects are small and inactive. To see the most active projects, find ''Sort by'' and pick ''Activity Level''.<br />
## Which (if any) of the most active projects do you recognize? {{Answer|Varies, maybe Moodle, Sakai, DSpace.}}<br />
# In the ''Sort by'' text box pick ''Relevance''. If necessary, go to the bottom of the screen and advance to pages 2, 3, ... in the listing until you find ''KDE Education'', and click on it.<br />
## From the ''KDE Education'' page, click on ''Code Locations'' (on the right side). Are any of the repo locations on GitHub? {{Answer|No, all are on kde.org (as of 2019-01)}}<br />
## Go back to ''KDE Education'', and click on ''Similar Projects'' (below ''Code Locations''). How many similar projects are listed? {{Answer|~10 (as of 2019-01)}}<br />
## This page contains general information for the similar projects. What info is shown for each? {{Answer|name, activity level, language, license (as of 2019-01)}}<br />
# Repeat your OpenHub search for both "humanitarian" and "disaster management", or terms that interests you.<br />
## How many projects did each search return? {{Answer|Varies. ~30 for humanitarian, ~30 for disaster mgmt (as of 2019-01)}}<br />
# Some projects show "Activity Not Available". Click on the pyramid icon and read the page shown. Why is "activity not available"? {{Answer|OpenHub could not access or analysis project data.}}<br />
# Click on ''Organizations'' (near the top of the main OpenHub page).<br />
## What info is shown? {{Answer|Most active orgs, newest orgs, stats by sector, etc (as of 2019-01)}}<br />
# From ''Organizations'', search for "OpenMRS".<br />
## Do the search results show projects or organizations? {{Answer|Organizations}} <br />
## Find the project "OpenMRS Core". When was the last commit? {{Answer|Varies. 11 months ago (as of 2019-01)}}<br />
# Go back to '''GitHub''' and search for the project "OpenMRS Core". When was the last commit? {{Answer|Varies. 4 days ago (as of 2019-01)}}<br />
## Why do you think these sites have different info? {{Answer|OpenHub might be looking in the wrong place, or misreading data.}}<br />
# What are some benefits & drawbacks of searching for a project in both GitHub & OpenHub? {{Answer|???}}<br />
<br />
=== Deliverables ===<br />
<br />
* ''POSSE Attendees'': Please post the answers to these questions on your foss2serve user wiki page.<br />
* ''Students'': Wiki posting describing your explorations of GitHub and OpenHub.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor.<br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor might encounter using this activity?<br />
<br />
=== Variants and Adaptations: ===<br />
<br />
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt POGIL-style combined FOSS Field Trip and Project Evaluation] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
30-60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser.<br />
|author=<br />
|source=<br />
[http://www.xcitegroup.org/softhum/doku.php?id=f:assignment_ossfieldtrip1detail Detailed FOSS Field Trip]<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Introduction]]<br />
[[Category:CS Principles]]<br />
[[Category:CS1]]<br />
[[Category: Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/FOSS_Field_Trip_(Activity)FOSS Field Trip (Activity)2019-04-14T14:58:22Z<p>Darci.burdge: /* Part 2 - OpenHub */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS Field Trip - Browsing for FOSS Projects<br />
|overview= <br />
Learners will explore the breadth of available FOSS projects as well as differences between GitHub and OpenHub.<br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Search for FOSS projects on both GitHub and OpenHub.<br />
# Use and describe different features of GitHub and OpenHub.<br />
|process skills=<br />
# Critical Thinking<br />
# Information Processing<br />
}}<br />
<br />
=== Background ===<br />
<br />
FOSS predates the web, but the web is now essential for most FOSS projects.<br />
People locate and access FOSS projects on the web, and FOSS communities collaborate on the web.<br />
A FOSS project has a set of files (including source code, documentation, etc), usually organized into folders.<br />
Most FOSS projects keep the complete history of every file, to know what changes were made, by who, and when.<br />
The set of files and their history is a '''repository''', or a '''repo''' for short.<br />
<br />
Most FOSS projects also use web-based collaborative tools to develop and share code and documentation, <br />
track who does what, and discuss questions, problems, and suggestions.<br />
A software platform with these tools is a '''forge'''.<br />
Some forges support ''one'' FOSS project (usually a ''large'' project),<br />
and other forges host ''many'' independent FOSS projects.<br />
Well known forges include [https://github.com GitHub], [https://sourceforge.net SourceForge], and [https://bitbucket.org Bitbucket].<br />
Note that the software used by such sites is also called a '''forge''';<br />
for example, [https://gitlab.com GitLab], [https://redmine.org RedMine], and [https://trac.edgewall.org Trac]<br />
are FOSS forges that anyone can install and modify, unlike [https://github.com GitHub].<br />
<br />
This activity also uses '''OpenHub''' (formerly '''Ohloh'''), <br />
which is ''not'' a forge, but mines data from forges to analyze project activity.<br />
<br />
=== Directions ===<br />
<br />
* ''POSSE Attendees'': Post your answers on your foss2serve wiki page.<br />
* ''Students'': Ask your instructor how to report your answers.<br />
<br />
==== Part 1 - GitHub ====<br />
<br />
In Part 1 you will search '''GitHub''' for projects. Do the following:<br />
# Open a new browser tab and go to: https://github.com<br />
# Find the search box near the top of the page, type "education", and press enter or click on the search icon.<br />
## How many ''repositories'' are found for "education"? {{Answer|~25,000 (as of 2019-01)}}<br />
## How many of these repos use the JavaScript language? (Hint: Find a summary table.) {{Answer|~3000 (as of 2019-01)}}<br />
## In the first page of results, which repo was updated ''most'' recently? Which was updated ''least'' recently? {{Answer|Answers will vary, and may range from a few hours ago to several years ago.}}<br />
# Many repos are small and inactive. To see the most active repos, find ''Sort'' and pick ''most stars''. <br />
## Which ''education'' repo has the most stars? How many? {{Answer|freeCodeCamp with ~300k (as of 2019-01)}}<br />
# Click on this repo to see its overview page. Scroll down past the list of files to see a project description.<br />
# In GitHub, each reported problem or suggestion is an '''issue''', the code and documentation to fix an issue is a '''pull request''', and a pull request that is accepted and added to a repo is a '''commit'''. Each issue and pull request is either ''open'' (in progress) or ''closed'' (done). (You will learn more about all of this later.)<br />
## At the top of the overview page, click on the ''Issues'' tab. You should see a list. How many issues are ''open''? ''closed''? {{Answer|~350 and ~13k for freeCodeCamp (as of 2019-01)}}<br />
## Click on the ''Pull requests'' tab. You should see a list. How many pull requests are ''open''? ''closed''? {{Answer|~5000 and ~16k for freeCodeCamp (as of 2019-01)}}<br />
## Click on the ''Insights'' tab. What do you see? {{Answer|Bargraphs of issues, pull requests, and commits this week.}}<br />
## Within ''Insights'', go to the left menu and click on ''Commits''. What do you see? {{Answer|A bargraph showing the number of commits each week for the last year.}}<br />
# Go back to the main GitHub page.<br />
## Search for "humanitarian" projects. How many repos are found? {{Answer|~350 (as of 2019-01)}}<br />
## Find ''HTBox/crisischeckin''. How many stars does it have? What language(s) does it use? When was the last update? {{Answer|~200 stars, C#, date will vary (as of 2019-01)}}<br />
## Search for "disaster management", or terms that interest you. How many repos are found? {{Answer|Varies}}<br />
<br />
Keep the GitHub browser tab open as you move on to Part 2.<br />
<br />
==== Part 2 - OpenHub ====<br />
<br />
In Part 2, you will search '''OpenHub''' for projects. Do the following:<br />
# Open a new browser tab and go to: https://www.openhub.net<br />
# In the search box, type "education".<br />
## The listing shows the number of ''pages'', not the number of ''projects''. By default, each page shows 10 projects. How many ''projects'' were found? {{Answer|~230 pages -> ~2300 projects (as of 2019-01)}}<br />
# Many projects are small and inactive. To see the most active projects, find ''Sort by'' and pick ''Activity Level''.<br />
## Which (if any) of the most active projects do you recognize? {{Answer|Varies, maybe Moodle, Sakai, DSpace.}}<br />
# In the ''Sort by'' text box pick ''Relevance''. If necessary, go to the bottom of the screen and advance to pages 2, 3, ... in the listing until you find ''KDE Education'', and click on it.<br />
## From the ''KDE Education'' page, click on ''Code Locations'' (on the right side). Are any of the repo locations on GitHub? {{Answer|No, all are on kde.org (as of 2019-01)}}<br />
## Go back to ''KDE Education'', and click on ''Similar Projects'' (below ''Code Locations''). How many similar projects are listed? {{Answer|~10 (as of 2019-01)}}<br />
## Look through the similar projects. What info is shown for each? {{Answer|name, activity level, language, license (as of 2019-01)}}<br />
# Repeat your OpenHub search for both "humanitarian" and "disaster management", or terms that interests you.<br />
## How many projects did each search return? {{Answer|Varies. ~30 for humanitarian, ~30 for disaster mgmt (as of 2019-01)}}<br />
# Some projects show "Activity Not Available". Click on the pyramid icon and read the page shown. Why is "activity not available"? {{Answer|OpenHub could not access or analysis project data.}}<br />
# Click on ''Organizations'' (near the top of the main OpenHub page).<br />
## What info is shown? {{Answer|Most active orgs, newest orgs, stats by sector, etc (as of 2019-01)}}<br />
# From ''Organizations'', search for "OpenMRS".<br />
## Do the search results show projects or organizations? {{Answer|Organizations}} <br />
## Find the project "OpenMRS Core". When was the last commit? {{Answer|Varies. 11 months ago (as of 2019-01)}}<br />
# Go back to '''GitHub''' and search for the project "OpenMRS Core". When was the last commit? {{Answer|Varies. 4 days ago (as of 2019-01)}}<br />
## Why do you think these sites have different info? {{Answer|OpenHub might be looking in the wrong place, or misreading data.}}<br />
# What are some benefits & drawbacks of searching for a project in both GitHub & OpenHub? {{Answer|???}}<br />
<br />
=== Deliverables ===<br />
<br />
* ''POSSE Attendees'': Please post the answers to these questions on your foss2serve user wiki page.<br />
* ''Students'': Wiki posting describing your explorations of GitHub and OpenHub.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor.<br />
They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor might encounter using this activity?<br />
<br />
=== Variants and Adaptations: ===<br />
<br />
[https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt POGIL-style combined FOSS Field Trip and Project Evaluation] used by [[User:Cmurphy|Chris Murphy]] in his [[FOSS Course, UPenn, Murphy]].<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
30-60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser.<br />
|author=<br />
|source=<br />
[http://www.xcitegroup.org/softhum/doku.php?id=f:assignment_ossfieldtrip1detail Detailed FOSS Field Trip]<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Introduction]]<br />
[[Category:CS Principles]]<br />
[[Category:CS1]]<br />
[[Category: Good Draft]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_1IRC Meeting 12019-04-12T22:41:51Z<p>Darci.burdge: /* Minutes */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== To Connect ==<br />
<br />
* Start an IRC client. If you don't have a client installed, there are many free options since many IRC clients are open source. A good client choice is Hexchat. You can get it here: [https://hexchat.github.io/downloads.html Hexchat Downloads]. Hexchat clients are available for Windows or as flatpacks for many Linux versions.<br />
* Connect to freenode with this command:<br />
<code>/attach webchat.freenode.net/</code><br />
* Join the foss2serve channel with this command:<br />
<code>/join #foss2serve</code><br />
<br />
* Another approach is to use Web-based IRC. This is especially useful if you are having difficulty getting an IRC client to work (which sometimes happens due to firewalls). A good option is: [https://webchat.freenode.net/ Webchat on Freenode] If you use this option, just create a Nickname and enter "#foss2serve" (without the quotes) as the channel.<br />
<br />
== Goals ==<br />
<br />
'''IRC Meeting 1''' has the following goals:<br />
<br />
* To provide an opportunity for everyone to introduce themselves, and start to get to know a few of their fellow participants<br />
* To allow people who have never used IRC a chance to use some basic features and see some features demonstrated<br />
* To briefly discuss HFOSS projects<br />
* To provide participants with an opportunity to discuss progress on stage 1 activities<br />
<br />
We expect that some people in the course will be quite familiar with IRC, others will have only passing familiarity, and some to have no prior experience at all. We ask that everyone participate, whether this is completely new or completely familiar. <br />
<br />
The discussion will be informal, but to provide some structure, we will loosely follow this agenda:<br />
<br />
== Agenda ==<br />
<br />
* '''Introductions''' - We'll go through the list of attendees and have each person say something about themselves. A sentence or so is fine.<br />
* '''Basic IRC features''' - team members or others present can demonstrate a few basic features. Some that might be covered include:<br />
** Chat<br />
*** Just type and press enter to say something<br />
** IRC Commands - start with a "/" <br />
*** '''/help''' - provides a pointer to command info<br />
*** '''/nick''' - set or change your nickname<br />
*** '''/me''' <action> - indicate that you are performing an action <br />
**** ''example'': /me waves hello<br />
*** '''/away''' and '''/back''' - mark yourself as not available or having returned<br />
*** Start your comment with someone's nick followed by a colon to direct your comment to that person <br />
**** ''example'': jamie: did you understand?<br />
*** Type someone's nick in a comment to get their attention<br />
**** ''example'': please check with jamie<br />
**** IRC clients will typically signal, e.g., by flashing the IRC icon<br />
*** GUI IRC clients may provide menus in place of many commands<br />
*** A more complete list: http://www.ircbeginner.com/ircinfo/ircc-commands.html<br />
** Meetbot - will create a log of the entire meeting and also a summary of the meeting <br />
*** Commands to the meetbot start with "#" and mostly control what appears in the summary<br />
**** #startmeeting <meeting topic> - start meeting<br />
**** #topic <topic> - start new topic<br />
**** #info|#agree|#action <details> - note info, decision, action item<br />
**** #link <url> <description> - note & describe link<br />
**** #endmeeting - end meeting<br />
*** A more complete list: http://meetbot.debian.net/Manual.html<br />
** Questions about IRC - anyone who has questions about IRC can ask them at any point during the IRC<br />
* '''HFOSS Projects''' - in the weeks ahead we'll be asking you to select an HFOSS project to investigate and to which you might potentially contribute. We'll use this IRC for a short discussion of the projects, perhaps including a few words about student participation in these projects in the past.<br />
** see [[HFOSS Communities]]<br />
** You can also sign up for an HFOSS project on the wiki<br />
* '''Good of the order'''<br />
** Please remember to log your progress in the spreadsheet - your feedback is always valued<br />
<br />
At each IRC meeting, several POSSE team members will facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will get to talk some without the conversation getting too confusing. <br />
<br />
Please jump in and try things! The main goal of this meeting is to learn and have some fun playing with IRC.<br />
<br />
== Minutes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
** Because the meetbot was not running on 2017-05-22, the minutes for this meeting is available at (the rest are available at the link above): [[File:POSSE_IRC_2017-05-20T09-02-EDT.txt|Minutes from 2017-05-22, 09:02 AM - EDT]]<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_1IRC Meeting 12019-04-12T22:41:35Z<p>Darci.burdge: /* Minutes */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== To Connect ==<br />
<br />
* Start an IRC client. If you don't have a client installed, there are many free options since many IRC clients are open source. A good client choice is Hexchat. You can get it here: [https://hexchat.github.io/downloads.html Hexchat Downloads]. Hexchat clients are available for Windows or as flatpacks for many Linux versions.<br />
* Connect to freenode with this command:<br />
<code>/attach webchat.freenode.net/</code><br />
* Join the foss2serve channel with this command:<br />
<code>/join #foss2serve</code><br />
<br />
* Another approach is to use Web-based IRC. This is especially useful if you are having difficulty getting an IRC client to work (which sometimes happens due to firewalls). A good option is: [https://webchat.freenode.net/ Webchat on Freenode] If you use this option, just create a Nickname and enter "#foss2serve" (without the quotes) as the channel.<br />
<br />
== Goals ==<br />
<br />
'''IRC Meeting 1''' has the following goals:<br />
<br />
* To provide an opportunity for everyone to introduce themselves, and start to get to know a few of their fellow participants<br />
* To allow people who have never used IRC a chance to use some basic features and see some features demonstrated<br />
* To briefly discuss HFOSS projects<br />
* To provide participants with an opportunity to discuss progress on stage 1 activities<br />
<br />
We expect that some people in the course will be quite familiar with IRC, others will have only passing familiarity, and some to have no prior experience at all. We ask that everyone participate, whether this is completely new or completely familiar. <br />
<br />
The discussion will be informal, but to provide some structure, we will loosely follow this agenda:<br />
<br />
== Agenda ==<br />
<br />
* '''Introductions''' - We'll go through the list of attendees and have each person say something about themselves. A sentence or so is fine.<br />
* '''Basic IRC features''' - team members or others present can demonstrate a few basic features. Some that might be covered include:<br />
** Chat<br />
*** Just type and press enter to say something<br />
** IRC Commands - start with a "/" <br />
*** '''/help''' - provides a pointer to command info<br />
*** '''/nick''' - set or change your nickname<br />
*** '''/me''' <action> - indicate that you are performing an action <br />
**** ''example'': /me waves hello<br />
*** '''/away''' and '''/back''' - mark yourself as not available or having returned<br />
*** Start your comment with someone's nick followed by a colon to direct your comment to that person <br />
**** ''example'': jamie: did you understand?<br />
*** Type someone's nick in a comment to get their attention<br />
**** ''example'': please check with jamie<br />
**** IRC clients will typically signal, e.g., by flashing the IRC icon<br />
*** GUI IRC clients may provide menus in place of many commands<br />
*** A more complete list: http://www.ircbeginner.com/ircinfo/ircc-commands.html<br />
** Meetbot - will create a log of the entire meeting and also a summary of the meeting <br />
*** Commands to the meetbot start with "#" and mostly control what appears in the summary<br />
**** #startmeeting <meeting topic> - start meeting<br />
**** #topic <topic> - start new topic<br />
**** #info|#agree|#action <details> - note info, decision, action item<br />
**** #link <url> <description> - note & describe link<br />
**** #endmeeting - end meeting<br />
*** A more complete list: http://meetbot.debian.net/Manual.html<br />
** Questions about IRC - anyone who has questions about IRC can ask them at any point during the IRC<br />
* '''HFOSS Projects''' - in the weeks ahead we'll be asking you to select an HFOSS project to investigate and to which you might potentially contribute. We'll use this IRC for a short discussion of the projects, perhaps including a few words about student participation in these projects in the past.<br />
** see [[HFOSS Communities]]<br />
** You can also sign up for an HFOSS project on the wiki<br />
* '''Good of the order'''<br />
** Please remember to log your progress in the spreadsheet - your feedback is always valued<br />
<br />
At each IRC meeting, several POSSE team members will facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will get to talk some without the conversation getting too confusing. <br />
<br />
Please jump in and try things! The main goal of this meeting is to learn and have some fun playing with IRC.<br />
<br />
== Minutes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
** Because the meetbot was not running on 2017-05-22, the minutes for this meeting is available at(the rest are available at the link above): [[File:POSSE_IRC_2017-05-20T09-02-EDT.txt|Minutes from 2017-05-22, 09:02 AM - EDT]]<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdgehttp://foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-12T22:30:24Z<p>Darci.burdge: /* The Sahana Eden Project (https://sahanafoundation.org/eden/) */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to FOSS Project Anatomy<br />
|overview= <br />
Learners will gain a high level familiarity with the structure, processes, and tools used in FOSS projects.<br />
|prerequisites=<br />
None<br />
|objectives=<br />
# Identify high-level components of and terminology associated with a HFOSS project.<br />
# Discuss that implementation process and tools can vary from project to project.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
[http://producingoss.com/en/index.html Producing Open Source Software] by Karl Fogel<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Directions ===<br />
<br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
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.<br />
<br />
'''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. <br />
<br />
'''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].<br />
<br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
<br />
'''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: [https://en.wikipedia.org/wiki/Version_control Wikipedia page on version control].<br />
<br />
'''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].<br />
<br />
=== Guided Tour ===<br />
<br />
==== The Sugar Labs Project (http://sugarlabs.org/) ====<br />
<br />
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. You will be asked to answer questions and to make observations. Your responses should be placed on your wiki page.<br />
<br />
'''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 roles. On your wiki page: <br />
* Summarize the roles that you think would be most applicable for your students. <br />
* What are the commonalities across roles? What are the differences? <br />
<br />
'''Tracker --''' An overview of the Sugar Labs bug tracker may be found [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems here]. A specific query on the Sugar Labs bug tracker can be found [https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&desc=1&order=id here]. On your wiki page:<br />
* Describe the general process for submitting a bug. <br />
* Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.<br />
<br />
'''Repository --''' https://github.com/sugarlabs/sugar/<br />
Click the "Commits" link and determine the date of last commit (an update of the repository).<br />
* Record the date on your wiki page. <br />
<br />
'''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]. On your wiki page:<br />
* Describe how the release cycle and roadmap update are related. <br />
<br />
'''Communication --''' Sugar Labs promotes communication among its community members in the following ways.<br />
* IRC: https://wiki.sugarlabs.org/go/Internet_Relay_Chat <br />
* Mailing lists: https://wiki.sugarlabs.org/go/Mailing_Lists<br />
* Blog: http://planet.sugarlabs.org/<br />
* Wiki: http://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki<br />
<br />
==== The Sahana Eden Project (https://sahanafoundation.org/eden/) ====<br />
<br />
Read the information found [http://eden.sahanafoundation.org/ here] to get an overview of the goals of the project and the types of contributions one can make.<br />
<br />
'''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. On your wiki page:<br />
<br />
* Follow the links to each of the groups listed and summarize the information you find there. 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?<br />
<br />
'''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.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket. <br />
<br />
'''Repository --''' https://github.com/sahana/eden Click the "Commits" link and determine the date of last commit (an update of the repository).<br />
* Record the date on your wiki page. <br />
<br />
'''Release cycle --''' Information about Sahana Eden's release cycle and roadmap can be found [http://eden.sahanafoundation.org/roadmap here]. <br />
* Include a brief entry on your wiki page that summarizes the information you find here.<br />
<br />
'''Communication --''' Sahana Eden promotes communication among its community members in the following ways.<br />
* Chat (via Slack): http://eden.sahanafoundation.org/wiki/Chat <br />
* Mailing lists: http://wiki.sahanafoundation.org/community/mailing_lists<br />
* Google Groups: https://groups.google.com/forum/?fromgroups#!forum/sahana-eden<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Notes on your user wiki page summarizing selected observations made while exploring HFOSS projects.<br />
<br />
= Notes for Instructors =<br />
<br />
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.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Variants and Adaptations ===<br />
<br />
[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]].<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=Heidi Ellis and Darci Burdge<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Introduction]]<br />
[[Category:CS Principles]]<br />
[[Category:Sahana]]<br />
[[Category:Sugar Labs]]</div>Darci.burdgehttp://foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-12T22:13:00Z<p>Darci.burdge: /* The Sahana Eden Project (https://sahanafoundation.org/eden/) */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to FOSS Project Anatomy<br />
|overview= <br />
Learners will gain a high level familiarity with the structure, processes, and tools used in FOSS projects.<br />
|prerequisites=<br />
None<br />
|objectives=<br />
# Identify high-level components of and terminology associated with a HFOSS project.<br />
# Discuss that implementation process and tools can vary from project to project.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
[http://producingoss.com/en/index.html Producing Open Source Software] by Karl Fogel<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Directions ===<br />
<br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
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.<br />
<br />
'''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. <br />
<br />
'''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].<br />
<br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
<br />
'''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: [https://en.wikipedia.org/wiki/Version_control Wikipedia page on version control].<br />
<br />
'''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].<br />
<br />
=== Guided Tour ===<br />
<br />
==== The Sugar Labs Project (http://sugarlabs.org/) ====<br />
<br />
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. You will be asked to answer questions and to make observations. Your responses should be placed on your wiki page.<br />
<br />
'''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 roles. On your wiki page: <br />
* Summarize the roles that you think would be most applicable for your students. <br />
* What are the commonalities across roles? What are the differences? <br />
<br />
'''Tracker --''' An overview of the Sugar Labs bug tracker may be found [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems here]. A specific query on the Sugar Labs bug tracker can be found [https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&desc=1&order=id here]. On your wiki page:<br />
* Describe the general process for submitting a bug. <br />
* Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.<br />
<br />
'''Repository --''' https://github.com/sugarlabs/sugar/<br />
Click the "Commits" link and determine the date of last commit (an update of the repository).<br />
* Record the date on your wiki page. <br />
<br />
'''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]. On your wiki page:<br />
* Describe how the release cycle and roadmap update are related. <br />
<br />
'''Communication --''' Sugar Labs promotes communication among its community members in the following ways.<br />
* IRC: https://wiki.sugarlabs.org/go/Internet_Relay_Chat <br />
* Mailing lists: https://wiki.sugarlabs.org/go/Mailing_Lists<br />
* Blog: http://planet.sugarlabs.org/<br />
* Wiki: http://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki<br />
<br />
==== The Sahana Eden Project (https://sahanafoundation.org/eden/) ====<br />
<br />
Read the information found [http://eden.sahanafoundation.org/ here] to get an overview of the goals of the project and the types of contributions one can make.<br />
<br />
'''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. On your wiki page:<br />
<br />
* Follow the links to each of the groups listed and summarize the information you find there. 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?<br />
<br />
'''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.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket. <br />
<br />
'''Repository --''' https://github.com/sahana/eden Click the "Commits" link and determine the date of last commit (an update of the repository).<br />
* Record the date on your wiki page. <br />
<br />
'''Release cycle --''' Information about Sahana Eden's release cycle and roadmap can be found [http://eden.sahanafoundation.org/roadmap here]. <br />
* Include a brief entry on your wiki page that summarizes the information you find here.<br />
<br />
'''Communication --''' Sahana Eden promotes communication among its community members in the following ways.<br />
* IRC: http://eden.sahanafoundation.org/wiki/Chat <br />
* Mailing lists: http://wiki.sahanafoundation.org/community/mailing_lists<br />
* Google Groups: https://groups.google.com/forum/?fromgroups#!forum/sahana-eden<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Notes on your user wiki page summarizing selected observations made while exploring HFOSS projects.<br />
<br />
= Notes for Instructors =<br />
<br />
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.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Variants and Adaptations ===<br />
<br />
[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]].<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=Heidi Ellis and Darci Burdge<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Introduction]]<br />
[[Category:CS Principles]]<br />
[[Category:Sahana]]<br />
[[Category:Sugar Labs]]</div>Darci.burdgehttp://foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-12T22:08:16Z<p>Darci.burdge: /* The Sugar Labs Project (http://sugarlabs.org/) */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to FOSS Project Anatomy<br />
|overview= <br />
Learners will gain a high level familiarity with the structure, processes, and tools used in FOSS projects.<br />
|prerequisites=<br />
None<br />
|objectives=<br />
# Identify high-level components of and terminology associated with a HFOSS project.<br />
# Discuss that implementation process and tools can vary from project to project.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
[http://producingoss.com/en/index.html Producing Open Source Software] by Karl Fogel<br />
<br />
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. <br />
<br />
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.<br />
<br />
=== Directions ===<br />
<br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
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.<br />
<br />
'''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. <br />
<br />
'''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].<br />
<br />
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. <br />
<br />
'''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. <br />
<br />
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. <br />
<br />
'''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: [https://en.wikipedia.org/wiki/Version_control Wikipedia page on version control].<br />
<br />
'''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].<br />
<br />
=== Guided Tour ===<br />
<br />
==== The Sugar Labs Project (http://sugarlabs.org/) ====<br />
<br />
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. You will be asked to answer questions and to make observations. Your responses should be placed on your wiki page.<br />
<br />
'''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 roles. On your wiki page: <br />
* Summarize the roles that you think would be most applicable for your students. <br />
* What are the commonalities across roles? What are the differences? <br />
<br />
'''Tracker --''' An overview of the Sugar Labs bug tracker may be found [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems here]. A specific query on the Sugar Labs bug tracker can be found [https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&desc=1&order=id here]. On your wiki page:<br />
* Describe the general process for submitting a bug. <br />
* Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.<br />
<br />
'''Repository --''' https://github.com/sugarlabs/sugar/<br />
Click the "Commits" link and determine the date of last commit (an update of the repository).<br />
* Record the date on your wiki page. <br />
<br />
'''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]. On your wiki page:<br />
* Describe how the release cycle and roadmap update are related. <br />
<br />
'''Communication --''' Sugar Labs promotes communication among its community members in the following ways.<br />
* IRC: https://wiki.sugarlabs.org/go/Internet_Relay_Chat <br />
* Mailing lists: https://wiki.sugarlabs.org/go/Mailing_Lists<br />
* Blog: http://planet.sugarlabs.org/<br />
* Wiki: http://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki<br />
<br />
==== The Sahana Eden Project (https://sahanafoundation.org/eden/) ====<br />
<br />
Read the information found [http://eden.sahanafoundation.org/ here] to get an overview of the goals of the project and the types of contributions one can make.<br />
<br />
'''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. On your wiki page:<br />
<br />
* Follow the links to each of the groups listed below and summarize the information you find there. 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?<br />
<br />
'''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.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket. <br />
<br />
'''Repository --''' https://github.com/sahana/eden Click the "Commits" link and determine the date of last commit (an update of the repository).<br />
* Record the date on your wiki page. <br />
<br />
'''Release cycle --''' Information about Sahana Eden's release cycle and roadmap can be found [http://eden.sahanafoundation.org/roadmap here]. <br />
* Include a brief entry on your wiki page that summarizes the information you find here.<br />
<br />
'''Communication --''' Sahana Eden promotes communication among its community members in the following ways.<br />
* IRC: http://eden.sahanafoundation.org/wiki/Chat <br />
* Mailing lists: http://wiki.sahanafoundation.org/community/mailing_lists<br />
* Google Groups: https://groups.google.com/forum/?fromgroups#!forum/sahana-eden<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Notes on your user wiki page summarizing selected observations made while exploring HFOSS projects.<br />
<br />
= Notes for Instructors =<br />
<br />
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.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Variants and Adaptations ===<br />
<br />
[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]].<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=Heidi Ellis and Darci Burdge<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Introduction]]<br />
[[Category:CS Principles]]<br />
[[Category:Sahana]]<br />
[[Category:Sugar Labs]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2019-04-12T21:58:46Z<p>Darci.burdge: /* Part C */</p>
<hr />
<div>__NOTOC__<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be able to fully benefit from the face-to-face portion of the workshop. Please send any comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
<!--<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be reimbursed for travel expenses to the face-to-face portion of the workshop. Please send all comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
--><br />
<br />
'''NOTE: Many of the activities below could take much more time than the estimate given. If you find yourself going over the time allotment, you may be going deeper than is needed to prepare for POSSE Stage 2. While deeper exploration is welcomed, once you pass the estimated time you should feel free to wrap up the activity, complete the deliverable, and move on.'''<br />
<br />
==== [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 5th'''<br />
<br />
'''Approximately 5-5.5 hours''' <br />
<br />
The activities in these first two weeks will start to introduce you to the world of FOSS projects, the community of faculty interested in student participation in FOSS projects, and a few of the basic communication tools commonly used in FOSS projects.<br />
<br />
# '''[[Intro to FOSS (Activity)]]''' – 60 minutes<br />
# '''[[Teaching Open Source (Activity)]]''' (Join TOS) - 30 minutes<br />
#* Participants sign up for TOS list and explore the TOS community<br />
# '''[[Intro to Wiki (Activity)]]''' - 30-45 minutes<br />
#* Provides an overview of wikis and short exercise in which participants create their own page and post an introduction<br />
# '''[[Intro to IRC (Activity)]]''' - 60-75 minutes <br />
#* Provides an overview of IRC including features and function and an introduction to the role of IRC in FOSS projects<br />
# '''[[IRC Meeting 1]]''' - 60 minutes - the week of April 29, day and time to be determined<br />
#* Introductions<br />
#* Discussion of HFOSS projects<br />
# '''[[Intro to FOSS Project Anatomy (Activity)]]''' - 60 minutes<br />
#* A walk through of the major tools and interactions found in a FOSS project.<br />
<br />
=== Part B ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 26th'''<br />
<br />
'''Approximately 5-5.5 hours'''<br />
# '''[[FOSS Field Trip (Activity)]]''' - 60 minutes <br />
#* The results of this will be discussed during the third IRC meeting<br />
# '''[[Project Evaluation (Activity)]]''' - 60-90 minutes - Post results to your wiki page<br />
#* Pared down evaluation of HFOSS project based on the evaluation metric.<br />
#* The results of this will be discussed during the third IRC meeting and also used during stage 2<br />
# '''[[Intro to Copyright and Licensing (Activity)]]''' - 40-60 minutes, post your responses to your wiki page.<br />
# '''[[FOSS in Courses 1 (Instructors)]]''' - 60 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 2]]''' - 60 minutes - the week of May 20, day and time to be determined<br />
# Sign up for Stage 2 groups [[Stage2 Groups|here]]. Sign up for one project-based group and one or two course-based groups.<br />
<br />
=== Part C ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due June 16th'''<br />
<br />
'''Approximately 4 hours'''<br />
# '''[[Intro to Bug Trackers (Activity)]]''' - 60 minutes<br />
# '''[[Intro to GitHub (Activity)]]''' - 60 minutes<br />
# '''[[FOSS in Courses 2 (Instructors)]]''' - 60-90 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 3]]''' - 60 minutes - the week of June 10, day and time to be determined<br />
<br />
'''Optional:''' If you have time and are sure of your project:<br />
# '''Download/Install''' project of your choosing - 60 minutes <br />
#* Go to [[HFOSS Communities]] and find your project<br />
#** Follow download/install link for your project<br />
#* Limit your efforts to 60 minutes or so<br />
<br />
'''Remember to log your progress in the sheet.'''<br />
<br />
[[Category:POSSE]]<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2019-04-12T21:53:27Z<p>Darci.burdge: /* Part C */</p>
<hr />
<div>__NOTOC__<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be able to fully benefit from the face-to-face portion of the workshop. Please send any comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
<!--<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be reimbursed for travel expenses to the face-to-face portion of the workshop. Please send all comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
--><br />
<br />
'''NOTE: Many of the activities below could take much more time than the estimate given. If you find yourself going over the time allotment, you may be going deeper than is needed to prepare for POSSE Stage 2. While deeper exploration is welcomed, once you pass the estimated time you should feel free to wrap up the activity, complete the deliverable, and move on.'''<br />
<br />
==== [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 5th'''<br />
<br />
'''Approximately 5-5.5 hours''' <br />
<br />
The activities in these first two weeks will start to introduce you to the world of FOSS projects, the community of faculty interested in student participation in FOSS projects, and a few of the basic communication tools commonly used in FOSS projects.<br />
<br />
# '''[[Intro to FOSS (Activity)]]''' – 60 minutes<br />
# '''[[Teaching Open Source (Activity)]]''' (Join TOS) - 30 minutes<br />
#* Participants sign up for TOS list and explore the TOS community<br />
# '''[[Intro to Wiki (Activity)]]''' - 30-45 minutes<br />
#* Provides an overview of wikis and short exercise in which participants create their own page and post an introduction<br />
# '''[[Intro to IRC (Activity)]]''' - 60-75 minutes <br />
#* Provides an overview of IRC including features and function and an introduction to the role of IRC in FOSS projects<br />
# '''[[IRC Meeting 1]]''' - 60 minutes - the week of April 29, day and time to be determined<br />
#* Introductions<br />
#* Discussion of HFOSS projects<br />
# '''[[Intro to FOSS Project Anatomy (Activity)]]''' - 60 minutes<br />
#* A walk through of the major tools and interactions found in a FOSS project.<br />
<br />
=== Part B ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 26th'''<br />
<br />
'''Approximately 5-5.5 hours'''<br />
# '''[[FOSS Field Trip (Activity)]]''' - 60 minutes <br />
#* The results of this will be discussed during the third IRC meeting<br />
# '''[[Project Evaluation (Activity)]]''' - 60-90 minutes - Post results to your wiki page<br />
#* Pared down evaluation of HFOSS project based on the evaluation metric.<br />
#* The results of this will be discussed during the third IRC meeting and also used during stage 2<br />
# '''[[Intro to Copyright and Licensing (Activity)]]''' - 40-60 minutes, post your responses to your wiki page.<br />
# '''[[FOSS in Courses 1 (Instructors)]]''' - 60 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 2]]''' - 60 minutes - the week of May 20, day and time to be determined<br />
# Sign up for Stage 2 groups [[Stage2 Groups|here]]. Sign up for one project-based group and one or two course-based groups.<br />
<br />
=== Part C ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due June 16th'''<br />
<br />
'''Approximately 4 hours'''<br />
# '''[[Intro to Bug Trackers (Activity)]]''' - 60 minutes<br />
# '''[[Intro to GitHub (Activity)]]''' - 60 minutes<br />
# '''[[FOSS in Courses 2 (Instructors)]]''' - 60-90 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 3]]''' - 60 minutes - the week of June 10 (day/time to be determined)<br />
<br />
'''Optional:''' If you have time and are sure of your project:<br />
# '''Download/Install''' project of your choosing - 60 minutes <br />
#* Go to [[HFOSS Communities]] and find your project<br />
#** Follow download/install link for your project<br />
#* Limit your efforts to 60 minutes or so<br />
<br />
'''Remember to log your progress in the sheet.'''<br />
<br />
[[Category:POSSE]]<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2019-04-12T21:52:07Z<p>Darci.burdge: /* Part B */</p>
<hr />
<div>__NOTOC__<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be able to fully benefit from the face-to-face portion of the workshop. Please send any comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
<!--<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be reimbursed for travel expenses to the face-to-face portion of the workshop. Please send all comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
--><br />
<br />
'''NOTE: Many of the activities below could take much more time than the estimate given. If you find yourself going over the time allotment, you may be going deeper than is needed to prepare for POSSE Stage 2. While deeper exploration is welcomed, once you pass the estimated time you should feel free to wrap up the activity, complete the deliverable, and move on.'''<br />
<br />
==== [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 5th'''<br />
<br />
'''Approximately 5-5.5 hours''' <br />
<br />
The activities in these first two weeks will start to introduce you to the world of FOSS projects, the community of faculty interested in student participation in FOSS projects, and a few of the basic communication tools commonly used in FOSS projects.<br />
<br />
# '''[[Intro to FOSS (Activity)]]''' – 60 minutes<br />
# '''[[Teaching Open Source (Activity)]]''' (Join TOS) - 30 minutes<br />
#* Participants sign up for TOS list and explore the TOS community<br />
# '''[[Intro to Wiki (Activity)]]''' - 30-45 minutes<br />
#* Provides an overview of wikis and short exercise in which participants create their own page and post an introduction<br />
# '''[[Intro to IRC (Activity)]]''' - 60-75 minutes <br />
#* Provides an overview of IRC including features and function and an introduction to the role of IRC in FOSS projects<br />
# '''[[IRC Meeting 1]]''' - 60 minutes - the week of April 29, day and time to be determined<br />
#* Introductions<br />
#* Discussion of HFOSS projects<br />
# '''[[Intro to FOSS Project Anatomy (Activity)]]''' - 60 minutes<br />
#* A walk through of the major tools and interactions found in a FOSS project.<br />
<br />
=== Part B ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 26th'''<br />
<br />
'''Approximately 5-5.5 hours'''<br />
# '''[[FOSS Field Trip (Activity)]]''' - 60 minutes <br />
#* The results of this will be discussed during the third IRC meeting<br />
# '''[[Project Evaluation (Activity)]]''' - 60-90 minutes - Post results to your wiki page<br />
#* Pared down evaluation of HFOSS project based on the evaluation metric.<br />
#* The results of this will be discussed during the third IRC meeting and also used during stage 2<br />
# '''[[Intro to Copyright and Licensing (Activity)]]''' - 40-60 minutes, post your responses to your wiki page.<br />
# '''[[FOSS in Courses 1 (Instructors)]]''' - 60 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 2]]''' - 60 minutes - the week of May 20, day and time to be determined<br />
# Sign up for Stage 2 groups [[Stage2 Groups|here]]. Sign up for one project-based group and one or two course-based groups.<br />
<br />
=== Part C ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due June 16th'''<br />
<br />
'''Approximately 4 hours'''<br />
# '''[[Intro to Bug Trackers (Activity)]]''' - 60 minutes<br />
# '''[[Intro to GitHub (Activity)]]''' - 60 minutes<br />
# '''[[FOSS in Courses 2 (Instructors)]]''' - 60-90 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 3]]''' - 60 minutes - the week of December 31st (day/time to be determined)<br />
<br />
'''Optional:''' If you have time and are sure of your project:<br />
# '''Download/Install''' project of your choosing - 60 minutes <br />
#* Go to [[HFOSS Communities]] and find your project<br />
#** Follow download/install link for your project<br />
#* Limit your efforts to 60 minutes or so<br />
<br />
'''Remember to log your progress in the sheet.'''<br />
<br />
[[Category:POSSE]]<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2019-04-12T21:49:11Z<p>Darci.burdge: /* Part A */</p>
<hr />
<div>__NOTOC__<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be able to fully benefit from the face-to-face portion of the workshop. Please send any comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
<!--<br />
Below is the schedule for the pre-workshop activities. Participants should finish all activities in a timely fashion in order to be reimbursed for travel expenses to the face-to-face portion of the workshop. Please send all comments to Lori Postner (lori.postner@ncc.edu) and Greg Hislop (hislop@drexel.edu).<br />
--><br />
<br />
'''NOTE: Many of the activities below could take much more time than the estimate given. If you find yourself going over the time allotment, you may be going deeper than is needed to prepare for POSSE Stage 2. While deeper exploration is welcomed, once you pass the estimated time you should feel free to wrap up the activity, complete the deliverable, and move on.'''<br />
<br />
==== [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 5th'''<br />
<br />
'''Approximately 5-5.5 hours''' <br />
<br />
The activities in these first two weeks will start to introduce you to the world of FOSS projects, the community of faculty interested in student participation in FOSS projects, and a few of the basic communication tools commonly used in FOSS projects.<br />
<br />
# '''[[Intro to FOSS (Activity)]]''' – 60 minutes<br />
# '''[[Teaching Open Source (Activity)]]''' (Join TOS) - 30 minutes<br />
#* Participants sign up for TOS list and explore the TOS community<br />
# '''[[Intro to Wiki (Activity)]]''' - 30-45 minutes<br />
#* Provides an overview of wikis and short exercise in which participants create their own page and post an introduction<br />
# '''[[Intro to IRC (Activity)]]''' - 60-75 minutes <br />
#* Provides an overview of IRC including features and function and an introduction to the role of IRC in FOSS projects<br />
# '''[[IRC Meeting 1]]''' - 60 minutes - the week of April 29, day and time to be determined<br />
#* Introductions<br />
#* Discussion of HFOSS projects<br />
# '''[[Intro to FOSS Project Anatomy (Activity)]]''' - 60 minutes<br />
#* A walk through of the major tools and interactions found in a FOSS project.<br />
<br />
=== Part B ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 26th'''<br />
<br />
'''Approximately 5-5.5 hours'''<br />
# '''[[FOSS Field Trip (Activity)]]''' - 60 minutes <br />
#* The results of this will be discussed during the third IRC meeting<br />
# '''[[Project Evaluation (Activity)]]''' - 60-90 minutes - Post results to your wiki page<br />
#* Pared down evaluation of HFOSS project based on the evaluation metric.<br />
#* The results of this will be discussed during the third IRC meeting and also used during stage 2<br />
# '''[[Intro to Copyright and Licensing (Activity)]]''' - 40-60 minutes, post your responses to your wiki page.<br />
# '''[[FOSS in Courses 1 (Instructors)]]''' - 60 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 2]]''' - 60 minutes - the week of December 3, day and time to be determined<br />
# Sign up for Stage 2 groups [[Stage2 Groups|here]]. Sign up for one project-based group and one or two course-based groups.<br />
<br />
=== Part C ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due June 16th'''<br />
<br />
'''Approximately 4 hours'''<br />
# '''[[Intro to Bug Trackers (Activity)]]''' - 60 minutes<br />
# '''[[Intro to GitHub (Activity)]]''' - 60 minutes<br />
# '''[[FOSS in Courses 2 (Instructors)]]''' - 60-90 minutes, post your selected activity to your wiki page.<br />
#* The results of this will be used in stage 2<br />
# '''[[IRC Meeting 3]]''' - 60 minutes - the week of December 31st (day/time to be determined)<br />
<br />
'''Optional:''' If you have time and are sure of your project:<br />
# '''Download/Install''' project of your choosing - 60 minutes <br />
#* Go to [[HFOSS Communities]] and find your project<br />
#** Follow download/install link for your project<br />
#* Limit your efforts to 60 minutes or so<br />
<br />
'''Remember to log your progress in the sheet.'''<br />
<br />
[[Category:POSSE]]<br />
[[Category:Instructor Activities]]</div>Darci.burdgehttp://foss2serve.org/index.php/SIGCSE_2019_POSSE_RoundupSIGCSE 2019 POSSE Roundup2019-02-27T19:42:07Z<p>Darci.burdge: /* Meeting Minutes */</p>
<hr />
<div>__NOTOC__<br />
=== February 27, 2019 - Minneapolis, MN ===<br />
<br />
=== Overview ===<br />
The workshop will explore approaches to student participation in HFOSS that provide more scaffolding and control for faculty taking initial steps with students. The discussion will focus on two areas:<br />
<br />
'''1. HFOSS Kits''' <br />
* HFOSS Kits provide a controlled, isolated practice environment where students can learn and practice open source skills. A kit contains:<br />
** A project sandbox - copy of an HFOSS project or selected artifacts from a live HFOSS project<br />
** Learning activities for the project sandbox<br />
** Directions and notes for an instructor on how to use the Kit<br />
* The goal of HFOSS Kits is to reduce instructor overhead in teaching basic open source skills. Kits will provide a predictable, controlled environment that can be re-set and re-used across multiple academic terms. Kits will also provide an opportunity for students to practice open source tasks repeatedly using real-world artifacts without needing to be concerned about burdening a project community.<br />
* Kits will provide experience with complexity and scale since the artifacts are from real projects. They will not have the benefit of observation and interaction with a project community. <br />
* Kits are intended as a stepping stone to participation in a live HFOSS projects. <br />
<br />
'''2. HFOSS Learning Projects''' <br />
* HFOSS Learning Projects are fully operational HFOSS projects that have student learning as a secondary objective. Characteristics of these projects include:<br />
** Fully functional project with an active client community<br />
** On-going product development, distribution, operation, and maintenance<br />
** Core committers include at least some faculty or students<br />
** Project welcomes and supports participation by students<br />
* The goal of HFOSS learning projects include:<br />
** To provide some projects where probability of successful student participation is higher because learning is an explicit secondary goal for the project<br />
** To increase positive social impact generated by college students in computing majors<br />
* There are already a handful of projects where faculty or college staff are the core contributors to open source projects. Several of these will provide a starting point for this effort.<br />
<br />
At the workshop, short presentations will summarize existing work in these areas. Breakout groups will generate ideas for application of these approaches in specific courses, and create specifications and prototypes of learning activities to support the identified uses.<br />
<br />
=== Meeting Location ===<br />
Hyatt: Greenway F (2nd floor) <br />
<br />
See [https://sigcse2019.sigcse.org/ SIGCSE 2019] for general information about the location.<br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday February 27, 2019<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome<br />
* Introductions<br />
* Plan for the day<br />
| Heidi, Greg<br />
|-<br />
| 9:00 AM<br />
| Overview<br />
* HFOSS Kits<br />
* HFOSS Learning Projects<br />
| Cam, Heidi, Stoney, Greg<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
| Breakout: HFOSS Kits<br />
* Learning outcomes and activities<br />
* Target HFOSS projects <br />
| All<br />
|-<br />
| 11:50<br />
| Lunch talk topic: HFOSS education and CSG<br />
* Is Computing for Social Good (CSG) well-established at your institution?<br />
* Can HFOSS help with development of professional responsibility among computing students?<br />
* Is there concern about HFOSS or CSG being deemed "political" or otherwise out of bounds in your program?<br />
| All<br />
|-<br />
| 12:00<br />
| Lunch - Hyatt Prairie Kitchen & Bar [https://www.hyatt.com/en-US/hotel/minnesota/hyatt-regency-minneapolis/msprm/dining]<br />
| All<br />
|-<br />
| 1:30 PM<br />
| HFOSS Learning Projects<br />
* [https://github.com/DickinsonCollege/ FarmData and AnmialData]<br />
* [https://openenergydashboard.github.io/ Open Energy Dashboard]<br />
* [https://github.com/Submitty/ Submitty]<br />
* [https://npfi.org/ Non-Profit FOSS Institute]<br />
* [https://github.com/LibreFoodPantry LibreFoodPantry]<br />
| Grant, Steve, Wes, Stoney, Allen<br />
|-<br />
| 3:00 PM<br />
| Break<br />
| All<br />
|-<br />
| 3:30 PM<br />
| Breakout: HFOSS Learning Projects<br />
| All<br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* Opportunities for HFOSS participation<br />
| Greg, Lori<br />
|-<br />
| 5:45 PM<br />
| Dinner - The Local - 931 Nicollet Mall [http://the-local.com/]<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
This POSSE Roundup is a workshop for instructors who have previously attended POSSE, or who have open source experience including contributing to an open source project. If you would like to register, please email Lori Postner at Lori.Postner@ncc.edu or Greg Hislop at hislop@drexel.edu. If you are not a POSSE alum, please provide a short summary of your experience with open source, including contributions to FOSS projects.<br />
<br />
NOTE: seating is limited, so please do not assume you are attending before receiving a confirmation from us.<br />
<br />
<br />
===== Meeting Minutes =====<br />
<br />
Kit Etherpad location:<br />
<br />
* https://pad.riseup.net/p/HFOSSKit1<br />
* https://pad.riseup.net/p/HFOSSKit2<br />
* https://pad.riseup.net/p/HFOSSKit3<br />
* https://pad.riseup.net/p/HFOSSKit4<br />
<br />
Learning Project Etherpad location:<br />
<br />
* https://pad.riseup.net/p/HFOSS-LP1<br />
* https://pad.riseup.net/p/HFOSS-LP2<br />
* https://pad.riseup.net/p/HFOSS-LP3<br />
* https://pad.riseup.net/p/HFOSS-LP4<br />
<br />
<br />
Contents will be saved after the session.<br />
<!--<br />
<br />
=== Opportunities for POSSE Alum ===<br />
Announcements coming!<br />
<br />
===== POGIL Training 2019 =====<br />
We have funding to send POSSE alum to regional POGIL training workshops. <br />
[https://www.pogil.org/2019-summer-regional-workshops Schedule of summer regional POGIL workshops]<br />
Please email Clif Kussmaul if you would like to attend a workshop this summer.<br />
<br />
<br />
===== Open Source Track at the Grace Hopper Convention 2019 =====<br />
The open source track at Hopper has a number of opportunities for POSSE alum to be involved. <br />
[https://ghc.anitab.org/2018-speakers/tracks/#os Hopper Open Source Track]<br />
If you are interested in putting together a paper, panel, workshop and would like to be put in contact with other POSSE alum please email Lori Postner.<br />
<br />
===== Funding Opportunities =====<br />
Looking to get more involved with open source in the classroom? We have limited funding to help professors design courses and be involved in a number of other activities. To get more information, please contact Greg Hislop or Heidi Ellis. <br />
<br />
===== Support =====<br />
<br />
We expect that most attendees will be staying for SIGCSE. For those needing to arrive on Tuesday to attend the POSSE roundup on Wednesday, we can provide support for the extra hotel night for a limited number of attendees. Please let us know ASAP if you are interested in this support.<br />
--><br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Darci.burdgehttp://foss2serve.org/index.php/SIGCSE_2019_POSSE_RoundupSIGCSE 2019 POSSE Roundup2019-02-27T19:41:48Z<p>Darci.burdge: /* Meeting Minutes */</p>
<hr />
<div>__NOTOC__<br />
=== February 27, 2019 - Minneapolis, MN ===<br />
<br />
=== Overview ===<br />
The workshop will explore approaches to student participation in HFOSS that provide more scaffolding and control for faculty taking initial steps with students. The discussion will focus on two areas:<br />
<br />
'''1. HFOSS Kits''' <br />
* HFOSS Kits provide a controlled, isolated practice environment where students can learn and practice open source skills. A kit contains:<br />
** A project sandbox - copy of an HFOSS project or selected artifacts from a live HFOSS project<br />
** Learning activities for the project sandbox<br />
** Directions and notes for an instructor on how to use the Kit<br />
* The goal of HFOSS Kits is to reduce instructor overhead in teaching basic open source skills. Kits will provide a predictable, controlled environment that can be re-set and re-used across multiple academic terms. Kits will also provide an opportunity for students to practice open source tasks repeatedly using real-world artifacts without needing to be concerned about burdening a project community.<br />
* Kits will provide experience with complexity and scale since the artifacts are from real projects. They will not have the benefit of observation and interaction with a project community. <br />
* Kits are intended as a stepping stone to participation in a live HFOSS projects. <br />
<br />
'''2. HFOSS Learning Projects''' <br />
* HFOSS Learning Projects are fully operational HFOSS projects that have student learning as a secondary objective. Characteristics of these projects include:<br />
** Fully functional project with an active client community<br />
** On-going product development, distribution, operation, and maintenance<br />
** Core committers include at least some faculty or students<br />
** Project welcomes and supports participation by students<br />
* The goal of HFOSS learning projects include:<br />
** To provide some projects where probability of successful student participation is higher because learning is an explicit secondary goal for the project<br />
** To increase positive social impact generated by college students in computing majors<br />
* There are already a handful of projects where faculty or college staff are the core contributors to open source projects. Several of these will provide a starting point for this effort.<br />
<br />
At the workshop, short presentations will summarize existing work in these areas. Breakout groups will generate ideas for application of these approaches in specific courses, and create specifications and prototypes of learning activities to support the identified uses.<br />
<br />
=== Meeting Location ===<br />
Hyatt: Greenway F (2nd floor) <br />
<br />
See [https://sigcse2019.sigcse.org/ SIGCSE 2019] for general information about the location.<br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday February 27, 2019<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome<br />
* Introductions<br />
* Plan for the day<br />
| Heidi, Greg<br />
|-<br />
| 9:00 AM<br />
| Overview<br />
* HFOSS Kits<br />
* HFOSS Learning Projects<br />
| Cam, Heidi, Stoney, Greg<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
| Breakout: HFOSS Kits<br />
* Learning outcomes and activities<br />
* Target HFOSS projects <br />
| All<br />
|-<br />
| 11:50<br />
| Lunch talk topic: HFOSS education and CSG<br />
* Is Computing for Social Good (CSG) well-established at your institution?<br />
* Can HFOSS help with development of professional responsibility among computing students?<br />
* Is there concern about HFOSS or CSG being deemed "political" or otherwise out of bounds in your program?<br />
| All<br />
|-<br />
| 12:00<br />
| Lunch - Hyatt Prairie Kitchen & Bar [https://www.hyatt.com/en-US/hotel/minnesota/hyatt-regency-minneapolis/msprm/dining]<br />
| All<br />
|-<br />
| 1:30 PM<br />
| HFOSS Learning Projects<br />
* [https://github.com/DickinsonCollege/ FarmData and AnmialData]<br />
* [https://openenergydashboard.github.io/ Open Energy Dashboard]<br />
* [https://github.com/Submitty/ Submitty]<br />
* [https://npfi.org/ Non-Profit FOSS Institute]<br />
* [https://github.com/LibreFoodPantry LibreFoodPantry]<br />
| Grant, Steve, Wes, Stoney, Allen<br />
|-<br />
| 3:00 PM<br />
| Break<br />
| All<br />
|-<br />
| 3:30 PM<br />
| Breakout: HFOSS Learning Projects<br />
| All<br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* Opportunities for HFOSS participation<br />
| Greg, Lori<br />
|-<br />
| 5:45 PM<br />
| Dinner - The Local - 931 Nicollet Mall [http://the-local.com/]<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
This POSSE Roundup is a workshop for instructors who have previously attended POSSE, or who have open source experience including contributing to an open source project. If you would like to register, please email Lori Postner at Lori.Postner@ncc.edu or Greg Hislop at hislop@drexel.edu. If you are not a POSSE alum, please provide a short summary of your experience with open source, including contributions to FOSS projects.<br />
<br />
NOTE: seating is limited, so please do not assume you are attending before receiving a confirmation from us.<br />
<br />
<br />
===== Meeting Minutes =====<br />
<br />
Kit Etherpad location:<br />
<br />
* https://pad.riseup.net/p/HFOSSKit1<br />
* https://pad.riseup.net/p/HFOSSKit2<br />
* https://pad.riseup.net/p/HFOSSKit3<br />
* https://pad.riseup.net/p/HFOSSKit4<br />
<br />
Learning Project Etherpad location:<br />
<br />
* https://pad.riseup.net/p/HFOSS-LP1<br />
* https://pad.riseup.net/p/HFOSS-LP2<br />
* https://pad.riseup.net/p/HFOSS-LP3<br />
* https://pad.riseup.net/p/HFOSS-LP4<br />
<br />
Contents will be saved after the session.<br />
<!--<br />
<br />
=== Opportunities for POSSE Alum ===<br />
Announcements coming!<br />
<br />
===== POGIL Training 2019 =====<br />
We have funding to send POSSE alum to regional POGIL training workshops. <br />
[https://www.pogil.org/2019-summer-regional-workshops Schedule of summer regional POGIL workshops]<br />
Please email Clif Kussmaul if you would like to attend a workshop this summer.<br />
<br />
<br />
===== Open Source Track at the Grace Hopper Convention 2019 =====<br />
The open source track at Hopper has a number of opportunities for POSSE alum to be involved. <br />
[https://ghc.anitab.org/2018-speakers/tracks/#os Hopper Open Source Track]<br />
If you are interested in putting together a paper, panel, workshop and would like to be put in contact with other POSSE alum please email Lori Postner.<br />
<br />
===== Funding Opportunities =====<br />
Looking to get more involved with open source in the classroom? We have limited funding to help professors design courses and be involved in a number of other activities. To get more information, please contact Greg Hislop or Heidi Ellis. <br />
<br />
===== Support =====<br />
<br />
We expect that most attendees will be staying for SIGCSE. For those needing to arrive on Tuesday to attend the POSSE roundup on Wednesday, we can provide support for the extra hotel night for a limited number of attendees. Please let us know ASAP if you are interested in this support.<br />
--><br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_3IRC Meeting 32018-10-20T15:08:48Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== Agenda ==<br />
<br />
'''IRC Meeting 3''' has the following goals:<br />
<br />
* Discuss progress - please continue to log feedback in the [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 activity evaluation spreadsheet]<br />
* Discuss the results of B.4 and C.3 (FOSS in Courses Planning I and II) and answer any questions<br />
** These will be used as a base for [[Stage 2 Activities]] so more detail is better<br />
* Sign up for Stage 2 groups [http://foss2serve.org/index.php/Stage2_Groups here]<br />
** Join one project and one or more courses<br />
* Enter your arrival and departure times in the [https://docs.google.com/spreadsheets/d/1QTaZ0C-rNoDhTiR3wVr5iM7t5SL7lijwhIpGLYsEqaE/edit#gid=0 POSSE Travel Arrangement Google Sheet] <br />
* Please make sure to arrive at Stage 2 with Git installed on your laptop and having completed C.2.<br />
<br />
== To Join ==<br />
<br />
Server: <br />
/attach irc.freenode.net<br />
Channel: <br />
/join #foss2serve<br />
<br />
As with previous IRC meetings, we'll have several of the POSSE team members to facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will get to talk some without the conversation getting too confusing.<br />
<br />
== Notes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_2IRC Meeting 22018-10-20T15:00:32Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== Agenda ==<br />
<br />
'''IRC Meeting 2''' has the following goals:<br />
* To provide an opportunity for all participants to provide an update on their progress on POSSE stage 1 activities (your feedback in the spreadsheet is important)<br />
* To allow participants to ask questions about POSSE [[Stage 1 Activities]]<br />
* To allow participants to talk about the courses in which they plan to use HFOSS<br />
* To allow participants to ask questions about POSSE [[Stage 2 Activities]]<br />
* To inform participants about signing up for [[Stage2 Groups]]<br />
* Reminder: please continue to log feedback in the [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 activity evaluation spreadsheet]<br />
<br />
== To Join ==<br />
<br />
Server: <br />
/attach http://webchat.freenode.net/<br />
Channel: <br />
/join #foss2serve<br />
<br />
As with the previous IRC meetings, we'll have several of the POSSE team members to facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will have the opportunity to ask questions.<br />
<br />
== Notes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_2IRC Meeting 22018-10-20T14:59:34Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== Agenda ==<br />
<br />
'''IRC Meeting 2''' has the following goals:<br />
* To provide an opportunity for all participants to provide an update on their progress on POSSE stage 1 activities (your feedback in the spreadsheet is important)<br />
* To allow participants to ask questions about POSSE [[Stage 1 Activities]]<br />
* To allow participants to talk about the courses in which they plan to use HFOSS<br />
* To allow participants to ask questions about POSSE [[Stage 2 Activities]]<br />
* To inform participants about signing up for [[Stage2 Groups]]<br />
* Reminder: please continue to log feedback in the [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 activity evaluation spreadsheet<br />
<br />
== To Join ==<br />
<br />
Server: <br />
/attach http://webchat.freenode.net/<br />
Channel: <br />
/join #foss2serve<br />
<br />
As with the previous IRC meetings, we'll have several of the POSSE team members to facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will have the opportunity to ask questions.<br />
<br />
== Notes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdgehttp://foss2serve.org/index.php/IRC_Meeting_3IRC Meeting 32018-10-20T14:58:59Z<p>Darci.burdge: /* Agenda */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== Agenda ==<br />
<br />
'''IRC Meeting 3''' has the following goals:<br />
<br />
* Discuss progress - please continue to log feedback in the [https://docs.google.com/spreadsheets/d/1HvgclSLZE4f1fDrw9S7ywP6MrMsAaWjWXATQ3W7H3Wg/edit#gid=0 activity evaluation spreadsheet]<br />
* Discuss the results of B.4 and C.3 (FOSS in Courses Planning I and II) and answer any questions<br />
** These will be used as a base for [[Stage 2 Activities]] so more detail is better<br />
* Sign up for Stage 2 groups [http://foss2serve.org/index.php/Stage2_Groups here]<br />
** Join one project and one or more courses<br />
* Enter your arrival and departure times in the [https://docs.google.com/spreadsheets/d/1r4gMu4uDE57nbM2iHSaWn5UXpaHWhyf_ddBL5Qm1qBg/edit#gid=0 POSSE Travel Arrangement Google Sheet] <br />
* Please make sure to arrive at Stage 2 with Git installed on your laptop and having completed C.2.<br />
<br />
== To Join ==<br />
<br />
Server: <br />
/attach irc.freenode.net<br />
Channel: <br />
/join #foss2serve<br />
<br />
As with previous IRC meetings, we'll have several of the POSSE team members to facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will get to talk some without the conversation getting too confusing.<br />
<br />
== Notes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Darci.burdge