http://www.foss2serve.org/api.php?action=feedcontributions&user=Stoney.jackson&feedformat=atomFoss2Serve - User contributions [en]2024-03-29T01:46:07ZUser contributionsMediaWiki 1.18.1http://www.foss2serve.org/index.php/Intro_to_GitHub_(Activity)Intro to GitHub (Activity)2019-05-31T13:28:15Z<p>Stoney.jackson: Fix link</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to GitHub<br />
|overview= <br />
Learner will get started with Git by working on a remote repository shared by other workshop learners.<br />
|prerequisites=<br />
* A basic understanding of command-line usage would be helpful, but not required.<br />
|objectives=<br />
* Install Git.<br />
* Configure Git.<br />
* Fork a GitHub repository.<br />
* Make changes to a repository.<br />
* Commit changes to a GitHub repository.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
For the impatient, you may skip down to the [Directions] section and get started. If you would prefer an overview of Git first, there are some great introductory videos on Git's site: http://git-scm.com/ . Namely:<br />
<br />
* Git Basics: What is Version Control?<br/><br/>If you are new to version control, or just want to gain a deeper understanding of it, this is 6 minutes of your life well spent.<br/><br/>[http://git-scm.com/video/what-is-version-control Watch the video]<br/><br/><br />
<br />
* Git Basics: What is Git?<br/><br/>This 8 minute video gives you a quick overview of git, why it exists, who it serves, what it can do, and explains some of its advantages.<br/><br/>[http://git-scm.com/video/what-is-git Watch the video]<br/><br/><br />
<br />
* Git Basics: Get Going with Git<br/><br/>This 4.5 minute video gives you an overview of installing and configuring git, as well as how to set up your first git repository. You could try to follow along and attempt each step, but I recommend just observing for now and appreciating the simplicity of setup. Later you'll complete a tutorial that will have you perform these same steps.<br/><br/>[http://git-scm.com/video/get-going Watch the video]<br/><br/><br />
<br />
* Git Basics: Quick Wins with Git<br/><br/>Still not convinced? Need more reasons to use Git? Whether you are gearing up for a water cooler debate about version control systems, or you just want to get a better understanding of the Git philosophy and the features that implement those philosophies, this 5 minute delivers.<br/><br/>[http://git-scm.com/video/quick-wins Watch the video]<br/><br/><br />
<br />
=== Directions ===<br />
<br />
1. Git: Download, install, and configure git as demonstrated in the videos above.<br />
2. GitHub: Go to https://github.com/foss2serve/github-rollcall-activity and follow the instructions there.<br />
<br />
=== Additional Information ===<br />
<br />
* Git website: http://git-scm.com<br />
* Repository location: https://github.com/foss2serve/github-rollcall-activity/<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Correctly completing the activity on GitHub will add you to the POSSE roll call list on GitHub.<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 />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<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 />
30-60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Stoney Jackson<br />
|source=<br />
None<br />
|license=<br />
{{License CC BY SA}}<br />
}}<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:Git]]<br />
[[Category:CS Principles]]<br />
[[Category:CS1]]<br />
[[Category:CS2]]<br />
[[Category:Good Draft]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_GitHub_(Activity)Intro to GitHub (Activity)2019-05-31T13:27:48Z<p>Stoney.jackson: Fix link</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to GitHub<br />
|overview= <br />
Learner will get started with Git by working on a remote repository shared by other workshop learners.<br />
|prerequisites=<br />
* A basic understanding of command-line usage would be helpful, but not required.<br />
|objectives=<br />
* Install Git.<br />
* Configure Git.<br />
* Fork a GitHub repository.<br />
* Make changes to a repository.<br />
* Commit changes to a GitHub repository.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
For the impatient, you may skip down to the [Directions] section and get started. If you would prefer an overview of Git first, there are some great introductory videos on Git's site: http://git-scm.com/ . Namely:<br />
<br />
* Git Basics: What is Version Control?<br/><br/>If you are new to version control, or just want to gain a deeper understanding of it, this is 6 minutes of your life well spent.<br/><br/>[http://git-scm.com/video/what-is-version-control Watch the video]<br/><br/><br />
<br />
* Git Basics: What is Git?<br/><br/>This 8 minute video gives you a quick overview of git, why it exists, who it serves, what it can do, and explains some of its advantages.<br/><br/>[http://git-scm.com/video/what-is-git Watch the video]<br/><br/><br />
<br />
* Git Basics: Get Going with Git<br/><br/>This 4.5 minute video gives you an overview of installing and configuring git, as well as how to set up your first git repository. You could try to follow along and attempt each step, but I recommend just observing for now and appreciating the simplicity of setup. Later you'll complete a tutorial that will have you perform these same steps.<br/><br/>[http://git-scm.com/video/get-going Watch the video]<br/><br/><br />
<br />
* Git Basics: Quick Wins with Git<br/><br/>Still not convinced? Need more reasons to use Git? Whether you are gearing up for a water cooler debate about version control systems, or you just want to get a better understanding of the Git philosophy and the features that implement those philosophies, this 5 minute delivers.<br/><br/>[http://git-scm.com/video/quick-wins Watch the video]<br/><br/><br />
<br />
=== Directions ===<br />
<br />
1. Git: Download, install, and configure git as demonstrated in the videos above.<br />
2. GitHub: Go to https://github.com/foss2serve/github-rollcall-activity and follow the instructions there.<br />
<br />
=== Additional Information ===<br />
<br />
* Git website: http://git-scm.com<br />
* Repository location: https://github.com/foss2serve/git-activity/<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Correctly completing the activity on GitHub will add you to the POSSE roll call list on GitHub.<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 />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<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 />
30-60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Stoney Jackson<br />
|source=<br />
None<br />
|license=<br />
{{License CC BY SA}}<br />
}}<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:Git]]<br />
[[Category:CS Principles]]<br />
[[Category:CS1]]<br />
[[Category:CS2]]<br />
[[Category:Good Draft]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_GitHub_(Activity)Intro to GitHub (Activity)2019-05-30T13:57:28Z<p>Stoney.jackson: Add instruction to download, install, and configure git.</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to GitHub<br />
|overview= <br />
Learner will get started with Git by working on a remote repository shared by other workshop learners.<br />
|prerequisites=<br />
* A basic understanding of command-line usage would be helpful, but not required.<br />
|objectives=<br />
* Install Git.<br />
* Configure Git.<br />
* Fork a GitHub repository.<br />
* Make changes to a repository.<br />
* Commit changes to a GitHub repository.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
For the impatient, you may skip down to the [Directions] section and get started. If you would prefer an overview of Git first, there are some great introductory videos on Git's site: http://git-scm.com/ . Namely:<br />
<br />
* Git Basics: What is Version Control?<br/><br/>If you are new to version control, or just want to gain a deeper understanding of it, this is 6 minutes of your life well spent.<br/><br/>[http://git-scm.com/video/what-is-version-control Watch the video]<br/><br/><br />
<br />
* Git Basics: What is Git?<br/><br/>This 8 minute video gives you a quick overview of git, why it exists, who it serves, what it can do, and explains some of its advantages.<br/><br/>[http://git-scm.com/video/what-is-git Watch the video]<br/><br/><br />
<br />
* Git Basics: Get Going with Git<br/><br/>This 4.5 minute video gives you an overview of installing and configuring git, as well as how to set up your first git repository. You could try to follow along and attempt each step, but I recommend just observing for now and appreciating the simplicity of setup. Later you'll complete a tutorial that will have you perform these same steps.<br/><br/>[http://git-scm.com/video/get-going Watch the video]<br/><br/><br />
<br />
* Git Basics: Quick Wins with Git<br/><br/>Still not convinced? Need more reasons to use Git? Whether you are gearing up for a water cooler debate about version control systems, or you just want to get a better understanding of the Git philosophy and the features that implement those philosophies, this 5 minute delivers.<br/><br/>[http://git-scm.com/video/quick-wins Watch the video]<br/><br/><br />
<br />
=== Directions ===<br />
<br />
1. Git: Download, install, and configure git as demonstrated in the videos above.<br />
2. GitHub: Go to https://github.com/foss2serve/git-activity and follow the instructions there.<br />
<br />
=== Additional Information ===<br />
<br />
* Git website: http://git-scm.com<br />
* Repository location: https://github.com/foss2serve/git-activity/<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Correctly completing the activity on GitHub will add you to the POSSE roll call list on GitHub.<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 />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<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 />
30-60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Stoney Jackson<br />
|source=<br />
None<br />
|license=<br />
{{License CC BY SA}}<br />
}}<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:Git]]<br />
[[Category:CS Principles]]<br />
[[Category:CS1]]<br />
[[Category:CS2]]<br />
[[Category:Good Draft]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-20T16:16:11Z<p>Stoney.jackson: Add Stoney as an author</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Issue Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of issue 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 issue tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a issue tracker and their priorities.<br />
# Identify and track the status of a particular issue in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue 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 />
# Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/GNOME.<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Milestones do three things: 1. they aggregate a set of issues and 2. they associate a deadline with those issues, and 3. they provide a progress bar to visualize the status of a milestone. Milestones can be used to collect issues for an upcoming release, organize a time-boxed development effort (as in a Scrum Sprint), or they can be used to collect issues that compose a larger feature to be implemented. Click on "milestones" in the left menu. Browse through two or three of them. How does GNOME appear to be using milestones?<br />
# Click on "Merge Requests" in the left menu. These look a lot like issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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 />
Stoney Jackson<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-18T15:12:54Z<p>Stoney.jackson: Add more description about milestones.</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Issue Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of issue 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 issue tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a issue tracker and their priorities.<br />
# Identify and track the status of a particular issue in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue 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 />
# Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/GNOME.<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Milestones do three things: 1. they aggregate a set of issues and 2. they associate a deadline with those issues, and 3. they provide a progress bar to visualize the status of a milestone. Milestones can be used to collect issues for an upcoming release, organize a time-boxed development effort (as in a Scrum Sprint), or they can be used to collect issues that compose a larger feature to be implemented. Click on "milestones" in the left menu. Browse through two or three of them. How does GNOME appear to be using milestones?<br />
# Click on "Merge Requests" in the left menu. These look a lot like issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-18T15:04:52Z<p>Stoney.jackson: Add link to GNOME on GitLab</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Issue Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of issue 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 issue tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a issue tracker and their priorities.<br />
# Identify and track the status of a particular issue in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue 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 />
# Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/GNOME.<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Click on "milestones" in the left menu. Browse through two or three of them. Then try to draw some conclusions. What are the elements of every milestone. What is the purpose of Milestones as GNOME is using them?<br />
# Click on "Merge Requests" in the left menu. These look a lot like issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-16T17:38:38Z<p>Stoney.jackson: </p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Issue Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of issue 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 issue tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a issue tracker and their priorities.<br />
# Identify and track the status of a particular issue in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue 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 />
# Open a browser and go to GNOME's issue tracker on GitLab .<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Click on "milestones" in the left menu. Browse through two or three of them. Then try to draw some conclusions. What are the elements of every milestone. What is the purpose of Milestones as GNOME is using them?<br />
# Click on "Merge Requests" in the left menu. These look a lot lick issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-16T17:33:53Z<p>Stoney.jackson: GNOME move to GitLab</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 />
Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue 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 />
# Open a browser and go to GNOME's issue tracker on GitLab .<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Click on "milestones" in the left menu. Browse through two or three of them. Then try to draw some conclusions. What are the elements of every milestone. What is the purpose of Milestones as GNOME is using them?<br />
# Click on "Merge Requests" in the left menu. These look a lot lick issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-16T17:24:15Z<p>Stoney.jackson: Update for GNOME's move to GitLab</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 />
# Open a browser and go to GNOME's issue tracker on GitLab .<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Click on "milestones" in the left menu. Browse through two or three of them. Then try to draw some conclusions. What are the elements of every milestone. What is the purpose of Milestones as GNOME is using them?<br />
# Click on "Merge Requests" in the left menu. These look a lot lick issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-16T17:24:02Z<p>Stoney.jackson: Update for GNOME's move to GitLab</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 />
# Open a browser and go to GNOME's issue tracker on GitLab .<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Click on "milestones" in the left menu. Browse through two or three of them. Then try to draw some conclusions. What are the elements of every milestone. What is the purpose of Milestones as GNOME is using them?<br />
# Click on "Merge Requests" in the left menu. These look a lot lick issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2019-05-16T17:23:47Z<p>Stoney.jackson: Update for GNOME's move to GitLab</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 />
# Open a browser and go to GNOME's issue tracker on GitLab .<br />
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issues has an issue number prefixed by its project name.)<br />
# What other information is available about each issue in this view?<br />
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.<br />
# Browse through a couple of issues. What additional information is provided on individual issues?<br />
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?<br />
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?<br />
# Click on "milestones" in the left menu. Browse through two or three of them. Then try to draw some conclusions. What are the elements of every milestone. What is the purpose of Milestones as GNOME is using them?<br />
# Click on "Merge Requests" in the left menu. These look a lot lick issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-20T13:59:18Z<p>Stoney.jackson: /* 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 code for Sahana Eden is hosted on GitHub: https://github.com/sahana/eden .<br />
<br />
Along the top of that page you will find an "Issues" tab and "Pull requests" tab. These are used to track bugs and feature requests and the efforts to address them. Review the contents of these tabs and then answer the questions below on your wiki page.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the "Labels" near the search box on either tab. Indicate the types/categories of issues listed on this page.<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-20T13:58:26Z<p>Stoney.jackson: /* 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 code for Sahana Eden is hosted on GitHub: https://github.com/sahana/eden .<br />
<br />
Along the top of that page you will find an "Issues" tab and "Pull requests" tab. These are used to track bugs and feature requests and the efforts to address them. Review the contents of these tabs and then answer the questions below on your wiki page.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the "Labels" near the search box on either tab. 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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-20T13:57:41Z<p>Stoney.jackson: /* 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 code for Sahana Eden is hosted on GitHub: https://github.com/sahana/eden .<br />
<br />
Along the top of that page you will find an "Issues" tab and "Pull requests" tab. These are used to track bugs and feature requests and the efforts to address them. Review the contents of these tabs and then answer the questions below on your wiki page.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the "Labels" link near the search box on either tab. 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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2019-04-20T13:56:59Z<p>Stoney.jackson: Sahana: direct participants to GitHub's issue tracker for 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 code for Sahana Eden is hosted on GitHub: [https://github.com/sahana/eden See the code].<br />
<br />
Along the top of that page you will find an "Issues" tab and "Pull requests" tab. These are used to track bugs and feature requests and the efforts to address them. Review the contents of these tabs and then answer the questions below on your wiki page.<br />
* How is the information here different than the information found on the Sugar Labs tracker page? <br />
* Click the "Labels" link near the search box on either tab. 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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_IRC_(Activity)Intro to IRC (Activity)2019-04-20T13:34:09Z<p>Stoney.jackson: Changed IRC channel from GNOME's #a11y to any of Fedora's channels</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to IRC (Internet Relay Chat)<br />
|overview= <br />
Learners will gain a basic understanding of IRC (Internet Relay Chat) as well as the role that IRC plays in open source software development. <br />
Participants will learn about IRC etiquette and explore the interactions that occur between members of an open source community.<br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Describe the importance of IRC as it relates to open source software development.<br />
# Connect to an IRC server and join a channel.<br />
# Participate in a brief interaction on an IRC channel.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
IRC (Internet Relay Chat) is an essential tool used by open source software developers. It allows members of the community, or those interested in becoming involved in the community, to communicate 24/7, regardless of their geographic location. IRC is much like Instant Messaging with a group. <br />
<br />
Bear in mind that ‘talking’ is not always a requirement. You will learn a great deal by ‘listening’, especially in the beginning. When you join a channel, it is not necessary to identify yourself or to say hi, you can simply 'lurk'. Feel free to ask questions, and note that it is not necessary to ask first if you can ask a question.<br />
<br />
IRC resources: <br />
* [http://www.irchelp.org IRC Help: tutorials and more] <br />
* http://teachingopensource.org/index.php/IRC<br />
* [http://www.ircbeginner.com/ircinfo/ircc-commands.html A list of IRC commands] <br />
* [http://www.greenday.net/chat/commands.html More complete list of IRC Commands]<br />
<br />
=== Directions ===<br />
Throughout this activity you will be asked to answer questions, make observations, and may wish to take notes. These should be posted to your wiki page.<br />
<br />
==== Part 1 – Walk through of IRC Conversation ====<br />
<br />
Download this sample [[Media:mouseTrapMeeting.pdf | IRC Conversation]]<br />
<br />
This conversation is part of a meeting being run with a '''meetbot'''. <br />
A [http://wiki.debian.org/MeetBot meetbot] is a type of "bot" (or program that simulates a human activity) that works in IRC channels to help take notes for a meeting. <br />
Note the dark green entries in the conversation that begin with a hashmark. These are meetbot commands. <br />
* The first line of the conversation shows "darci" starting the meeting.<br />
* "totally" is the name of the meetbot.<br />
* The #topics command sets the topic of the conversation and is one of several commands. <br />
<br />
As you review the conversation, you should:<br />
# Pay attention to the interactions that occur between community members.<br />
# Ignore the technical terms.<br />
# Accept that the content may be beyond your understanding at this point, your first step in being productively lost.<br />
# Answer the following questions on your wiki page:<br />
#* How do people interact? <br />
#* What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix?<br />
#* Are there any terms that seem to have special meaning?<br />
#* Can you make any other observations?<br />
# Now look at the [[Media:mousetrapBot2013-03-01.pdf | results of the meetbot]]. This shows you how each meetbot command is formatted into a legible page that summarizes the meeting. Some additional formatting may be needed, but it certainly provides a great starting point. Here's a link to the final version of the [https://wiki.gnome.org/Projects/MouseTrap/Meetings/20130301 meeting notes]. <br />
#* Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?<br />
<br />
==== Part 2 – Install and Start an IRC Client ====<br />
<br />
There are many IRC clients to choose from, below is a brief list of suggestions:<br />
# Windows and Linux: Hexchat (https://hexchat.github.io/) or Pidgin (https://pidgin.im/)<br />
# Mac OS X: Colloquy (http://colloquy.info/) <br />
<br />
Note that there are some locations or situations where the IRC port is blocked. In such cases you may want to use a web-based client:<br />
# Kiwiirc, supports the freenode server and you can access the foss2serve channel from here. - https://kiwiirc.com/client/irc.freenode.net/<br />
# Mibbit, allows you to connect to a variety of servers. - http://www.mibbit.com/<br />
<br />
==== Part 3 – Join and Observe Channel Discussion ====<br />
Observe the activity of two or three channels over a 24 hour period. You do not need to be physically present for this length of time. You can join the channel and let the IRC client record the communications that occur.<br />
<br />
Fedora uses a number of different channels: see https://fedoraproject.org/wiki/IRC . Join two or three of them.<br />
<br />
# Connect to freenode.net: /server freenode.net<br />
# Join a channel: /join #<channel-name> . For example, /join #fedora-devel<br />
# Summarize your observations on your wiki page. <br />
#* Pay particular attention to the ways that the communication in this channel differs from the sample dialog you examined in Part 1<br />
<br />
==== Part 4 – (Optional - Make your own channel and experiment) ====<br />
<br />
Sometimes the best way to figure out what's possible is just to play around and know you're not going to step on anyone's toes. In IRC you can create a channel by typing<br />
/join #channelname <br />
(and you can make "channelname" whatever made up thing that you want!).<br />
<br />
A variant of that is that if you type <br />
/join #yournick <br />
and no one has created the channel #yournick on that IRC server then a new channel called #yournick will be created and you'll automatically have Ops privileges. This is a fun way to experiment with Ops privs!<br />
<br />
Next, try one of the most useful commands (for almost any system, anywhere): help<br />
* Remember to precede it with the /, as that's what tells the client that it's a command, not text to be sent.<br />
* Invite another student to the your channel and try some of the commands that you can only do with Ops privileges <br />
* Record the commands you tried and what they did (in your own words) on your wiki page.<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: Be ready to participate in the upcoming IRC meeting:<br />
* Have the appropriate IRC client installed and running<br />
* Test that you can connect to the network<br />
* Test that you can access freenode and the foss2serve channel<br />
** /server irc.freenode.net/<br />
** /join #foss2serve<br />
<br />
POSSE and Students will deliver:<br />
# For Part 1, their observations/answers to the following questions:<br />
#* How do people interact?<br />
#* What is the pattern of communication?<br />
#* Are there any terms that seem to have special meaning?<br />
#* What advantages might IRC have over other real-time communication methods (like Google Chat or Facebook Messenger?) Are there potential disadvantages? <br />
#* Can you make any other observations?<br />
#* Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?<br />
# For Part 2: nothing to deliver, should have successfully installed IRC client<br />
# For Part 3: observations of the #a11y channel communications and how they differed from the sample dialog in Part 1.<br />
# For Part 4 (optional): a list of at least 5 commands that will work in the channel that was created, and what they mean.<br />
<br />
= Notes for Instructors = <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 />
Some possible questions:<br />
* For what purposes do FOSS projects use IRC channels?<br />
* Why choose IRC over another synchronous collaboration method (like a conference call)?<br />
* How can IRC be used to facilitate project management?<br />
* In your own words, explain how to find a channel and join it for whichever IRC client you prefer.<br />
<br />
<br />
{| class="wikitable"<br />
|- <br />
|'''Criteria''' ||'''Level 1 (fail)'''||'''Level 2 (pass)'''||'''Level 3 (good)'''||'''Level 4 (exceptional)''' <br />
|-<br />
|Understanding of importance of IRC in open source (from observations of IRC log) || Did not attempt observations || Minimum effort put into observations (one statement per question, for example) || Complete observations || Well thought-out observations that tie the material back to other knowledge (bonus question also a nice addition) <br />
|-<br />
|Ability to connect to an IRC server and join a channel || Did not attempt || Installed client but did not join channel || Installed client, joined channel || Installed client, joined channel, made good observations of project <br />
|-<br />
|Become familiar with the interactions that occur in an IRC channel (from Observations of HFOSS project) || Did not attempt observations || Minimum effort put into observations (one statement per question, for example) || Complete observations || Well thought-out observations that tie the material back to other knowledge<br />
|-<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* Some projects have multiple channels. There may be one for developers, another for documentation and another still for end users. These should all be listed on the project website. See, for example, [http://wiki.sahanafoundation.org/community/chat Sahana], which has:<br />
** Sahana : for general Sahana developer or user support from the community (starting point for most discussions)<br />
** Sahana-Meeting : for scheduled Sahana meetings<br />
** Sahana-Agasti : for Sahana Agasti-specific developer discussions<br />
** Sahana-Eden : for Sahana Eden-specific developer discussions<br />
** Sahana-GIS : for Sahana GIS-specific discussions<br />
<br />
* Depending on the project, its size, and the amount of activity on a project's channel, it may be necessary to determine an appropriate day for this observation. If there is a specific day/tim that the developers meet, you might want to schedule your observation for this day. You can join the channel and identify yourself as _afk (away from keyboard, for example joe_afk using the /nick command). When you return the following day, you will be able to observe the communication that occurred during the previous 24 hour period.<br />
<br />
*Note that many of the POSSE and OpenFE team hang out in the foss2serve channel throughout the day:<br />
** Connect to the server via the command: /server irc.freenode.net/<br />
** Join the foss2serve channel via the command: /join #foss2serve<br />
** Come join us!!!<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
HCI/Collaboration and Communication, HCI/Foundations, SE/Software Project Management<br />
|acm topic=<br />
* Synchronous Group Communication<br />
* Social models that inform interaction design, e.g., culture, communication, networks and organizations (*why* IRC and not something else)<br />
* Team Participation/Team Management<br />
|difficulty=<br />
Easy<br />
|time=<br />
60-75 minutes<br />
|environment=<br />
Internet access, a Web browser and an IRC client.<br />
|author=<br />
Darci Burdge, Heidi Ellis & Gina Likins<br />
|source=<br />
[http://129.25.203.54/xcitegroup/softhum/doku.php?id=f:assignments Communication and Community]<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for the Open Source Project ===<br />
<br />
What channels does your project use? Which would be most useful for students to join?<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]<br />
[[Category:CS Principles]]<br />
[[Category:Ready to Use]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_2_Activities/Stage_3_Planning_-_CapstoneStage 2 Activities/Stage 3 Planning - Capstone2018-06-20T18:14:33Z<p>Stoney.jackson: /* Brief description of the activity */</p>
<hr />
<div>== Group Participants ==<br />
Bo - b.kim@snhu.edu<br />
<br />
James - James.foster@wallawalla.edu<br />
<br />
Stoney - stoney.jackson@wne.edu<br />
<br />
Wei - wjin@ggc.edu<br />
<br />
== Planning an Initial HFOSS Learning Activity ==<br />
<br />
=== Course targeted for the activity ===<br />
Senior Capstone / Independent Study Course<br />
<br />
=== Brief description of the activity ===<br />
# Getting students to be connected to the developer communities through channels/email lists/etc (http://foss2serve.org/index.php/Open_Source_Communication_Activity_version2)<br />
# Identify a mode of communication and lurk/review over a period of time and then characterize its use.<br />
# Given a scenario find an example of a communication in one of the media and analyze it.<br />
# Community conventions for use of communication media (create a flowchart or some other diagram)<br />
<br />
=== Time you expect the HFOSS activity to take ===<br />
e.g. # classes, # homework assignments, # lab activities, etc.<br />
<br />
Whether the activity will be completed in class or out of class<br />
<br />
=== Relationship of this activity to course goals/objectives ===<br />
<br />
=== What students will submit upon completion of the activity ===<br />
<br />
=== Approach for assessing the student work ===<br />
<br />
=== Questions or concerns you have about implementing your activity ===<br />
<br />
=== Support you will need to implement your activity ===<br />
<br />
== Planning Stage 3 Activities ==<br />
<br />
=== Meetings ===<br />
<Identify meeting times. Find out HFOSS project meeting times.><br />
<br />
===Specific Tasks===<br />
<What will various group members do.> <br />
<br />
=== Resources ===<br />
<List any resources that you find><br />
<br />
== Other Notes ==<br />
<br />
Prior related POSSE groups, if any:<br />
<br />
<br />
<br />
<br />
<br />
[[Category:POSSE]]<br />
<br />
When creating an activity, remove it from the Formats category.<br />
[[Category:Formats]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_2_Activities/Stage_3_Planning_-_CapstoneStage 2 Activities/Stage 3 Planning - Capstone2018-06-20T18:12:19Z<p>Stoney.jackson: /* Planning an Initial HFOSS Learning Activity */</p>
<hr />
<div>== Group Participants ==<br />
Bo - b.kim@snhu.edu<br />
<br />
James - James.foster@wallawalla.edu<br />
<br />
Stoney - stoney.jackson@wne.edu<br />
<br />
Wei - wjin@ggc.edu<br />
<br />
== Planning an Initial HFOSS Learning Activity ==<br />
<br />
=== Course targeted for the activity ===<br />
Senior Capstone / Independent Study Course<br />
<br />
=== Brief description of the activity ===<br />
# Getting students to be connected to the developer communities through channels/email lists/etc (http://foss2serve.org/index.php/Open_Source_Communication_Activity_version2)<br />
# Identify a mode of comm and lurk/review over a period of time and then characterize its use.<br />
# Given a scenario find an example of a communication on one of the media and analyze it.<br />
<br />
=== Time you expect the HFOSS activity to take ===<br />
e.g. # classes, # homework assignments, # lab activities, etc.<br />
<br />
Whether the activity will be completed in class or out of class<br />
<br />
=== Relationship of this activity to course goals/objectives ===<br />
<br />
=== What students will submit upon completion of the activity ===<br />
<br />
=== Approach for assessing the student work ===<br />
<br />
=== Questions or concerns you have about implementing your activity ===<br />
<br />
=== Support you will need to implement your activity ===<br />
<br />
== Planning Stage 3 Activities ==<br />
<br />
=== Meetings ===<br />
<Identify meeting times. Find out HFOSS project meeting times.><br />
<br />
===Specific Tasks===<br />
<What will various group members do.> <br />
<br />
=== Resources ===<br />
<List any resources that you find><br />
<br />
== Other Notes ==<br />
<br />
Prior related POSSE groups, if any:<br />
<br />
<br />
<br />
<br />
<br />
[[Category:POSSE]]<br />
<br />
When creating an activity, remove it from the Formats category.<br />
[[Category:Formats]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/IRC_Meeting_3IRC Meeting 32018-06-11T14:42:29Z<p>Stoney.jackson: </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/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit?ts=5ae33a5d#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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage2_GroupsStage2 Groups2018-05-21T18:37:14Z<p>Stoney.jackson: /* 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 project and one course by entering your name below. We will pick projects based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Mozilla Developer Tools Accessibility] ===<br />
* Stoney<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Lori Postner<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <Name><br />
<br />
=== Note that the projects below are less likely to 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 />
== 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 />
* <Name><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 />
* Stoney<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 />
=== Mobile Application Development (Android) ===<br />
* Lori Postner<br />
<br />
=== Other course (include the name of the course) ===<br />
* <Name><br />
[[Category:POSSE]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage2_GroupsStage2 Groups2018-05-21T18:36:56Z<p>Stoney.jackson: /* Mozilla 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 project and one course by entering your name below. We will pick projects based on available facilitator coverage and attendee interest.<br />
<br />
<br />
== Projects ==<br />
<br />
=== [https://developer.mozilla.org/en-US/docs/Tools Mozilla Developer Tools Accessibility] ===<br />
* Stoney<br />
<br />
=== [https://world.openfoodfacts.org/ Open Food Facts] ===<br />
* Lori Postner<br />
<br />
=== [https://www.ushahidi.com/ Ushahidi] ===<br />
* <Name><br />
<br />
=== Note that the projects below are less likely to 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 />
== 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 />
* <Name><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 />
=== Mobile Application Development (Android) ===<br />
* Lori Postner<br />
<br />
=== Other course (include the name of the course) ===<br />
* <Name><br />
[[Category:POSSE]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2018-05-11T14:10:52Z<p>Stoney.jackson: </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 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 />
'''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/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 6th'''<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 30, 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 27th'''<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 21, 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 17th'''<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 11th (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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2018-05-11T14:10:13Z<p>Stoney.jackson: /* Part B: Due May 27th */</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 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 />
'''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/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 6th'''<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 30, 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 />
<br />
'''Due May 27th'''<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 21, 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: Due June 17th ===<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 11th (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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2018-05-11T14:09:44Z<p>Stoney.jackson: /* 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 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 />
'''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/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<!-- Changing header will break in-page links to this header --><br />
<br />
'''Due May 6th'''<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 30, 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: Due May 27th ===<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 21, 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: Due June 17th ===<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 11th (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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2018-05-11T14:07:38Z<p>Stoney.jackson: /* Part A: Due May 6th */</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 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 />
'''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/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit Log your progress here!] ====<br />
<br />
=== Part A ===<br />
<br />
Due May 6th<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 30, 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: Due May 27th ===<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 21, 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: Due June 17th ===<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 11th (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>Stoney.jacksonhttp://www.foss2serve.org/index.php/POSSE_2018-06POSSE 2018-062018-05-11T14:06:56Z<p>Stoney.jackson: /* Stage 1: April 23 - June 17 - Online activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
<!--<br />
README: To create a new POSSE page:<br />
# Update the announcement on the foss2serve.org homepage<br />
# Create a homepage for this POSSE. the page title is POSSE_yyyy-mm<br />
## Edit the page for the most recent POSSE, copy the entire contents, and paste into the new POSSE page.<br />
## Create the page for the new POSSE by changing the date & location in the title.<br />
## Change the dates for applications, the 3 stages, the 3 parts of Stage 1.<br />
## Change the link for the participants page.<br />
## Save the new POSSE page. <br />
# Edit the new participants page and set it up for this POSSE. An easy way to do this is to copy the prior participants page and delete all entries but the team<br />
# Edit the pages for Stage_1_Activities and Stage_2_Activities with due dates, IRC dates, etc.<br />
--><br />
<br />
===<center> POSSE - The Professors' Open Source Software Experience </center>===<br />
===<center>June 18-20, 2018 - Drexel University, Philadelphia, PA</center>===<br />
====<center><nowiki>http://foss2serve.org</nowiki>'''</center>====<br />
<!--<br />
====<center>[http://foss2serve.org/index.php/POSSE_Announcement_2017-04 Call for Participation]</center>====<br />
--><br />
====<center>[https://docs.google.com/forms/d/e/1FAIpQLSfwyz6liWKOdEL3im-JO6qutT8i8tC5SsFGcihr5puNlBFnUQ/viewform?c=0&w=1 Application]</center>====<br />
<center>Applications due: April 6, 2018; Notifications: April 16, 2018 </center><br />
<br />
====<center><font color='red'>Please note that due to NSF funding, only faculty members at U. S. institutions who are teaching in the United States are eligible for support.</font></center>====<br />
<br />
POSSE has three stages of participation: <br />
* [[Stage_1_Activities | Stage 1]] includes approximately 20 hours of online activities (both asynchronous and synchronous) over 8 weeks<br />
* [[Stage_2_Activities | Stage 2]] includes a 2.5 day face-to-face workshop<br />
* Stage 3 is ongoing participation in a community of faculty members who use HFOSS in their classes<br />
<br />
=== Welcome! ===<br />
<br />
Welcome to POSSE! This page provides some basic information to help you get started.<br />
<br />
=== Set Up ===<br />
There are several things that you should do to get set up for the POSSE experience. First, read this page thoroughly. Next, check that your login for this wiki works.<br />
<br />
=== Schedule ===<br />
This POSSE will include three stages. The schedule for these stages is shown below. <br />
<br />
==== Stage 1: April 23 - June 17 - Online activities ====<br />
The [[Stage_1_Activities | Stage 1 activities]] have been subdivided into three segments. Click on the link for each segment and please complete the activities by the due date. <br />
<br />
{| border="1" style="width:50%"<br />
|-<br />
| [[Stage_1_Activities#Part_A|Part A]]<br />
| Due by May 6, 2018<br />
|-<br />
| [[Stage_1_Activities#Part_B|Part B]]<br />
| Due by May 27, 2018<br />
|-<br />
| [[Stage_1_Activities#Part_C|Part C]]<br />
| Due by June 17, 2018<br />
|}<br />
<br />
==== Stage 2: June 18-20, 2018 - Workshop in Philadelphia, PA ====<br />
The [[Stage_2_Activities|Stage 2 activities]] occur face to face.<br />
<br />
====<font color='red'>Note that funding support for Stage 2 is dependent on completing all Stage 1 activities.</font>====<br />
<br />
==== Stage 3: June 20th and beyond - Small group participation in HFOSS projects and the POSSE community ====<br />
<br />
=== Logistics ===<br />
This POSSE provides support for travel, lodging, and meals. Details will be provided to participants by email.<br />
<br />
=== Participants ===<br />
[[POSSE 2018-06 Participants]]<br />
<br />
=== Tools ===<br />
# IRC:<br />
## First connect to the server via the command: /server irc.freenode.net<br />
## Second, join the foss2serve channel via the command: /join #foss2serve<br />
# [http://www.foss2serve.org/index.php/Main_Page Wiki]<br />
# [http://foss2serve.org/index.php/HFOSS_Communities POSSE HFOSS projects]<br />
<br />
=== IRC Meeting Minutes ===<br />
<br />
* https://meetbot-raw.fedoraproject.org/foss2serve/<br />
<br />
===Additional Information===<br />
<br />
If you have questions contact one of the team members. For local arrangements, contact Greg Hislop at hislop at drexel.edu<br />
<br />
[[Category:POSSE]]<br />
[[Category:POSSE 2018-06]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2018-05-11T13:23:18Z<p>Stoney.jackson: /* Part 1 - Bug Reports */</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 below.<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Copyright_and_Licensing_(Activity)Intro to Copyright and Licensing (Activity)2018-05-11T13:10:19Z<p>Stoney.jackson: /* Directions */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Copyright and Licensing (Activity)<br />
|overview=<br />
Participants will explore different types of licenses frequently used by open source projects.<br />
|prerequisites=<br />
None<br />
|objectives=<br />
* Identify a project’s license<br />
* Identify constraints license imposes on your contributions<br />
* Articulate whether or not you are comfortable contributing to a project with a given license<br />
|process skills=<br />
* Critical Thinking<br />
* Communication<br />
}}<br />
<br />
=== Background ===<br />
<br />
A quick YouTube search will yield a number of good videos on copyright and licensing. I recommend watching one or two on each topic: copyright and licensing. Here are a few of our favorites.<br />
<br />
* Copyright Clearance Center. “Copyright Basics”. 2010. https://youtu.be/Uiq42O6rhW4 . This video explains copyrights from a business perspective.<br />
* Intel Software. “Open Source Basics”. 2014. https://youtu.be/Tyd0FO0tko8 . This video explains how open source software is enabled through licensing.<br />
* Watch Now, UK. “Creative Commons & Copyright Info”. 2012. https://youtu.be/8YkbeycRa2A This video explains the purpose of licenses from a content producer’s view who wants to let other use their work without having to ask permission. It specifically talks about the Creative Commons licenses.<br />
* CppCon 2015: Kevin P. Fleming “A Crash Course in Open Source Licensing". https://youtu.be/cJIi-hIlCQM . A much more in-depth, longer talk on copyright, software, and open source licensing.<br />
<br />
=== Directions ===<br />
<br />
# Identify the license for the following projects (look for a LICENSE file in the project's root; if it's not there assume no license):<br />
#* https://github.com/openmrs/openmrs-core<br />
#* https://github.com/apache/incubator-fineract <br />
#* https://github.com/regulately/regulately-back-end<br />
# Go to https://tldrlegal.com/ . Look up each of the above licenses. Identify the “cans” the “cannots” and the “musts” for each.<br />
# For each license, state whether you would (or would not) be comfortable contributing code to that project and why (or why not).<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section answering the above questions.<br />
<br />
= Notes for Instructors =<br />
<br />
<br />
=== Assessment ===<br />
<br />
<br />
=== Comments ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/binaries/content/assets/education/cs2013_web_final.pdf''<br />
|difficulty=<br />
Easy to medium<br />
|time=<br />
40-60 minutes<br />
|environment=<br />
Internet access<br />
|author=<br />
Stoney Jackson and Karl Wurst<br />
|source=<br />
|license=<br />
''{{License CC BY SA}}''<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
--------------------<br />
[[Category:Learning Activity]]<br />
[[Category:Culture and Intellectual Property]]<br />
[[Category:Good Draft]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/SIGCSE_2018_POSSE_RoundupSIGCSE 2018 POSSE Roundup2018-02-16T14:30:10Z<p>Stoney.jackson: Adding</p>
<hr />
<div>__NOTOC__<br />
=== February 21, 2018 - Baltimore, MD ===<br />
<br />
<br />
==NOTE: Registration for this event is limited. See registration instructions at the bottom of this page ==<br />
<br />
=== Overview ===<br />
<br />
POSSE, the Professors’ Open Source Software Experience, prepares instructors to guide student participation in Humanitarian Free and Open Source Software (HFOSS) projects. 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. <br />
<br />
The workshop will allow faculty to work together in small groups to become more familiar with a selected HFOSS project. The group work will include getting the development environment installed, finding a bug, fixing it and submitted a patch back to the community. The groups will work under the guidance of a faculty member who has successfully contributed to the HFOSS project. The workshop structure of the day will emphasize active participation of attendees.<br />
<br />
=== Notes ===<br />
To be posted<br />
<br />
=== Meeting Location ===<br />
In the Baltimore Convention Center, room 302.<br />
<br />
=== Agenda ===<br />
We will spend much of the day working in small groups on several different HFOSS projects. For the groups working on the Mozilla Dev Tools Accessibility features and the group working on Ushahidi, the schedule will be:<br />
<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday February 21, 2018<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome and Overview:<br />
* Introductions<br />
* Plan for the day<br />
* HFOSS updates<br />
| Lori and Greg<br />
|-<br />
| 9:15 AM<br />
| <br />
Breakout: Development Environment Installation<br />
|<br />
|-<br />
| 10:15 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
|<br />
Breakout: Product walkthrough - developer and user views<br />
| <br />
|-<br />
| 12:00<br />
| Lunch - The Yard - 110 South Eutaw Street<br />
| All<br />
|-<br />
| 1:30 PM<br />
|<br />
Breakout: Picking a Bug to work on & becoming acquainted with the code base <br />
| <br />
|-<br />
| 3:00 PM<br />
|<br />
Break<br />
|<br />
|-<br />
| 3:30 PM<br />
|<br />
Breakout: Coding a bug fix<br />
<br />
Breakout: Contributing back<br />
| <br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* POGIL Summer workshops<br />
| Greg and Lori<br />
|-<br />
| 5:45 PM<br />
| Dinner - Pratt Street Ale House - 206 W Pratt St.<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
For the group working on the food bank project, the schedule will be:<br />
<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday February 21, 2018<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome and Overview:<br />
* Introductions<br />
* Plan for the day<br />
* HFOSS updates<br />
| Lori and Greg<br />
|-<br />
| 9:15 AM<br />
| <br />
Breakout: Overview of the food bank project<br />
* Overview of the application area<br />
* Discussion of relevant experience within the group and possible targets at each location<br />
* Functional areas discussion<br />
|<br />
|-<br />
| 10:15 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
|<br />
Breakout: Sub-groups in parallel<br />
* Group A: HFOSS project evaluation of known food projects<br />
* Group B: Explore food bank apps on the Play Store/Apple Store <br />
| <br />
|-<br />
| 12:00<br />
| Lunch - The Yard - 110 South Eutaw Street<br />
| All<br />
|-<br />
| 1:30 PM<br />
|<br />
Breakout: Design discussion for candidate features. Possible candidates include:<br />
* Expiration date vs. allowable use date (government database)<br />
* Food bank intake client forms that could be further automated for initial client contact and later contacts (Currently a google form)<br />
* Inventory tracking<br />
| <br />
|-<br />
| 3:00 PM<br />
|<br />
Break<br />
|<br />
|-<br />
| 3:30 PM<br />
|<br />
Breakout: Planning<br />
* Defining possible learning activities: selection from library or draft of new ones<br />
* Identifying target courses and what kind of activities students could do<br />
* Brainstorming: Next steps with students<br />
| <br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* POGIL Summer workshops<br />
| Greg and Lori<br />
|-<br />
| 5:45 PM<br />
| Dinner - Pratt Street Ale House - 206 W Pratt St.<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<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 />
===== Minutes: Mozilla DevTools Team =====<br />
<br />
Live etherpad: https://pad.riseup.net/p/HEjjP8gUfQgb<br />
Contents will be saved here after the session.<br />
<br />
===== Minutes: Ushahidi Team =====<br />
<br />
Live etherpad: https://pad.riseup.net/p/9zz16UpHb2h4<br />
Contents will be saved here after the session.<br />
<br />
===== Minutes: Foodbank Team =====<br />
<br />
Live etherpad: https://pad.riseup.net/p/KbuSCTZL4rVh<br />
Contents will be saved here after the session.<br />
<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>Stoney.jacksonhttp://www.foss2serve.org/index.php/SIGCSE_2018_POSSE_RoundupSIGCSE 2018 POSSE Roundup2018-02-16T14:08:07Z<p>Stoney.jackson: Remove Prep Section - Sent by email</p>
<hr />
<div>__NOTOC__<br />
=== February 21, 2018 - Baltimore, MD ===<br />
<br />
<br />
==NOTE: Registration for this event is limited. See registration instructions at the bottom of this page ==<br />
<br />
=== Overview ===<br />
<br />
POSSE, the Professors’ Open Source Software Experience, prepares instructors to guide student participation in Humanitarian Free and Open Source Software (HFOSS) projects. 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. <br />
<br />
The workshop will allow faculty to work together in small groups to become more familiar with a selected HFOSS project. The group work will include getting the development environment installed, finding a bug, fixing it and submitted a patch back to the community. The groups will work under the guidance of a faculty member who has successfully contributed to the HFOSS project. The workshop structure of the day will emphasize active participation of attendees.<br />
<br />
=== Notes ===<br />
To be posted<br />
<br />
=== Meeting Location ===<br />
In the Baltimore Convention Center, room 302.<br />
<br />
=== Agenda ===<br />
We will spend much of the day working in small groups on several different HFOSS projects. For the groups working on the Mozilla Dev Tools Accessibility features and the group working on Ushahidi, the schedule will be:<br />
<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday February 21, 2018<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome and Overview:<br />
* Introductions<br />
* Plan for the day<br />
* HFOSS updates<br />
| Lori and Greg<br />
|-<br />
| 9:15 AM<br />
| <br />
Breakout: Development Environment Installation<br />
|<br />
|-<br />
| 10:15 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
|<br />
Breakout: Product walkthrough - developer and user views<br />
| <br />
|-<br />
| 12:00<br />
| Lunch - The Yard - 110 South Eutaw Street<br />
| All<br />
|-<br />
| 1:30 PM<br />
|<br />
Breakout: Picking a Bug to work on & becoming acquainted with the code base <br />
| <br />
|-<br />
| 3:00 PM<br />
|<br />
Break<br />
|<br />
|-<br />
| 3:30 PM<br />
|<br />
Breakout: Coding a bug fix<br />
<br />
Breakout: Contributing back<br />
| <br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* POGIL Summer workshops<br />
| Greg and Lori<br />
|-<br />
| 5:45 PM<br />
| Dinner - Pratt Street Ale House - 206 W Pratt St.<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
For the group working on the food bank project, the schedule will be:<br />
<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday February 21, 2018<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome and Overview:<br />
* Introductions<br />
* Plan for the day<br />
* HFOSS updates<br />
| Lori and Greg<br />
|-<br />
| 9:15 AM<br />
| <br />
Breakout: Overview of the food bank project<br />
* Overview of the application area<br />
* Discussion of relevant experience within the group and possible targets at each location<br />
* Functional areas discussion<br />
|<br />
|-<br />
| 10:15 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
|<br />
Breakout: Sub-groups in parallel<br />
* Group A: HFOSS project evaluation of known food projects<br />
* Group B: Explore food bank apps on the Play Store/Apple Store <br />
| <br />
|-<br />
| 12:00<br />
| Lunch - The Yard - 110 South Eutaw Street<br />
| All<br />
|-<br />
| 1:30 PM<br />
|<br />
Breakout: Design discussion for candidate features. Possible candidates include:<br />
* Expiration date vs. allowable use date (government database)<br />
* Food bank intake client forms that could be further automated for initial client contact and later contacts (Currently a google form)<br />
* Inventory tracking<br />
| <br />
|-<br />
| 3:00 PM<br />
|<br />
Break<br />
|<br />
|-<br />
| 3:30 PM<br />
|<br />
Breakout: Planning<br />
* Defining possible learning activities: selection from library or draft of new ones<br />
* Identifying target courses and what kind of activities students could do<br />
* Brainstorming: Next steps with students<br />
| <br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* POGIL Summer workshops<br />
| Greg and Lori<br />
|-<br />
| 5:45 PM<br />
| Dinner - Pratt Street Ale House - 206 W Pratt St.<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<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 />
===== 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>Stoney.jacksonhttp://www.foss2serve.org/index.php/POSSEPOSSE2018-01-11T15:48:00Z<p>Stoney.jackson: /* POSSE Overview */ Fix apostrophe in Professors'</p>
<hr />
<div>===<center>POSSE</center>===<br />
===<center>Professional Development for Instructors Interested in Student Participation in Humanitarian Free and Open Source Software</center>===<br />
====<center><nowiki>http://foss2serve.org</nowiki></center>====<br />
<br />
== POSSE Overview ==<br />
POSSE is the Professors' Open Source Software Experience. POSSEs provide professional development for instructors interested in student participation in Humanitarian Free and Open Source Software (HFOSS)<br />
<br />
=== Upcoming POSSEs ===<br />
POSSE schedule for 2018 will be established shortly.<br />
<br />
We anticipate holding 1-2 POSSEs each year.<br />
<br />
=== What is POSSE? ===<br />
POSSE began as an outreach effort by Red Hat, Inc. to the higher education community. The goal was to help instructors learn about free and open source software (FOSS) so that they could incorporate FOSS into their courses. A description of the first POSSE workshops is contained [http://www.redhat.com/posse/ here]<br />
<br />
The first workshops were held in summer, so the POSSE acronym was adopted to stand for: '''Professor's Open Source Summer Experience'''.<br />
<br />
Later workshops have been held in other seasons, so the POSSE acronym has been re-interpreted to stand for: '''Professor's Open Source Software Experience'''.<br />
<br />
[http://blogs.whitman.edu/countingfromzero/2016/06/17/ive-got-a-posse/ One professor's observations on their POSSE experience] from June 2016.<br />
<br />
=== What is HFOSS? ===<br />
HFOSS stands for Humanitarian Free and Open Source Software. It is an acronym used to refer to the large and growing collection of open source projects that have some social benefit as their primary reason for existence. This includes projects that seek to address aspects of healthcare, disaster management, accessibility assistance, economic development, education, and other areas of social need.<br />
<br />
A growing group of faculty are exploring the learning and motivational potential of student participation in HFOSS projects. <br />
<br />
=== POSSE and HFOSS Together ===<br />
The current version of POSSE workshops combine an expanded version of the initial POSSE work with a focus on HFOSS projects. The effort is a collaboration between Red Hat and faculty interested in HFOSS. The current verion of POSSE also benefits from support provided by the National Science Foundation. The approach to POSSE has been revised and extended to create a more complete path for instructors. It includes technical topics related to FOSS and also pedagogical and curricular consideratoins. The approach to delivery uses online learning to extend participant interactions before and after a face-to-face workshop. Below is a brief outline of the faculty development model which underlies the approach as well as the outline for the three stages.<br />
<br />
=== Faculty Development Model ===<br />
Experience with POSSEs and with other NSF-funded workshops has highlighted the need for an integrated approach to faculty development that includes both the academic and FOSS perspectives.<br />
We propose a two-track, three-stage model for faculty to learn how to support student participation in HFOSS. The two tracks cover the dual HFOSS and academic content needed to support faculty. <br />
<br />
[[file:FacultyDevelopmentModel.jpg | Faculty Development Model ]]<br />
<br />
==== Stage 1 ====<br />
The [[Stage 1 Activities]] occur during the six weeks prior to the face-to-face meeting. Faculty members (participants) work independently and also interact with the foss2serve team and other participants in an online environment periodically. These activities are intended to prepare a faculty member to get the most out of a face-to-face workshop.<br />
The HFOSS track includes a series of activities on FOSS tools with an emphasis on communication tools as these support entance to the HFOSS communities. The goal is to get faculty familiar with the tools so that they can use them efficiently during the actual workshop. For the academic track, faculty members will be asked to identify places in their curriculum where student participation in HFOSS might be incorporated. These activities are intended to take approximately 15-20 hours in total and are divided into three two-week stages. IRC meetings will be held with groups of participants periodically to answer questions and help guide learning. Faculty members will also be introduced to an HFOSS community during stage 1.<br />
<br />
'''Guidelines for the activities:'''<br />
* Activities completed according to schedule within the six weeks prior to the workshop.<br />
* Each activity takes 30-90 minutes requiring 12-15 hours of work in the four weeks prior to the semester.<br />
* Most activities will involve reporting results on a wiki. <br />
* IRC meetings will be used to periodically talk about the results of activities.<br />
* The activities are broken down into two-week segments. All activities must be completed within a day or two of the end of the deadline. <br />
* More "pre-work" ideas from POSSE may be found here: http://teachingopensource.org/index.php/POSSE_curriculum<br />
* Look at http://teachingopensource.org/index.php/POSSE_curriculum#Monday when creating the activities below as learning objectives and good ideas reside here.<br />
<br />
==== Stage 2 ====<br />
A [[Stage 2 Activities | 2+-day face-to-face workshop]] comprises Stage 2. Following POSSE precedent, the workshop is lead by a team of representatives from FOSS organizations and academic POSSE alumni. Participants arrive for an evening meal and intro session on day 1, work all of day 2, work all of day 3 and end the afternoon of day 3. During this time, participants will learn how the material that they had been absorbing prior to the face-to-face event is used in actual FOSS projects. Participants will also learn ways to incorporate that material into their classes and to identify and/or create actual assignments.<br />
<br />
==== Stage 3 ====<br />
In order to support faculty after the workshop, stage 3 consists of interactions among small groups so that participants will have support while involving students in an HFOSS project in the classroom. This approach is based on research into small-group learning. These groups will be approximately 6-10 participants and organized around a particular HFOSS project. The idea being that faculty members can work collaboratively on the same project. In addition to these small groups, faculty members will also belong to their chosen HFOSS community.<br />
<br />
During Stage 3, POSSE participants will:<br />
* Join a small learning group.<br />
* Incorporate HFOSS into course<br />
* Work with other instructors and HFOSS community members to solve problems<br />
<br />
==== Previous POSSEs ====<br />
Information about recent POSSEs is available here:<br />
* [[ POSSE_2017-11 | POSSE 2017-11 (Raleigh, NC)]]<br />
* [[ POSSE_2017-07 | POSSE 2017-07 (Bologna, Italy) ]]<br />
* [[ POSSE_2017-04 | POSSE 2017-04 (San Francisco, CA) ]]<br />
* [[ POSSE_2016-11 | POSSE 2016-11 (Raleigh, NC) ]]<br />
* [[ POSSE_2016-06 | POSSE 2016-06 (Philadelphia, PA) ]]<br />
* [[ POSSE_2015-09 | POSSE 2015-09 (Raleigh, NC) ]]<br />
* [[ POSSE_2014-11 | POSSE 2014-11 (Raleigh, NC) ]]<br />
* [[ POSSE_2014-05 | POSSE 2014-05 (Philadelphia, PA) ]]<br />
* [[ POSSE_2013-06 | POSSE 2013-06 (Philadelphia, PA) ]]<br />
<br />
<br />
__NOTOC__<br />
[[Category: POSSE ]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/IRC_Meeting_1IRC Meeting 12017-05-25T15:05:11Z<p>Stoney.jackson: </p>
<hr />
<div>{{Category:IRC}}<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 />
* Discussion of IRC basic 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<br />
*** Commands start with a "/" <br />
*** /help provides a pointer to command info<br />
*** /nick to set or change your nickname<br />
*** /away and /back - To mark yourself as not available or as having returned<br />
*** /me to indicate that you are performing an action (e.g., /me waves hello)<br />
*** Type someone's nick in a comment to get their attention IRC clients will typically signal, e.g., by flashing the IRC icon<br />
*** nick: - beginning your comment with someones nick followed by a colon allows you indicate the person to whom you are directing your comment or whose question you are answering<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<br />
*** The 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 />
*** 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 />
* Discussion of 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 />
** You can also sign up for an HFOSS project on the wiki<br />
* Please remember to log your progress in the spreadsheet - your feedback is always valued<br />
* Good of the order<br />
<br />
At each of the 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 />
Please do jump in and try things! More than anything, the goal of this meeting is to learn and have some fun playing with IRC.<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 />
** Because the meetbot was not running on 2017-05-22, the minutes for this meeting is available below (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 />
== Minutes ==<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/IRC_Meeting_1IRC Meeting 12017-05-22T14:02:27Z<p>Stoney.jackson: Add minutes to IRC meeting</p>
<hr />
<div>{{Category:IRC}}<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 />
<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 />
* Discussion of IRC basic 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<br />
*** Commands start with a "/" <br />
*** /help provides a pointer to command info<br />
*** /nick to set or change your nickname<br />
*** /away and /back - To mark yourself as not available or as having returned<br />
*** /me to indicate that you are performing an action (e.g., /me waves hello)<br />
*** Type someone's nick in a comment to get their attention 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<br />
*** The 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 />
*** 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 />
* Discussion of 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 />
** You can also sign up for an HFOSS project on the wiki<br />
* Good of the order<br />
<br />
At each of the 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 />
Please do jump in and try things! More than anything, the goal of this meeting is to learn and have some fun playing with IRC.<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 />
== Minutes ==<br />
<br />
Because the meetbot was not running on 2017-05-22, the minutes for this meeting is available below:<br />
<br />
* [[File:POSSE_IRC_2017-05-20T09-02-EDT.txt|Minutes from 2017-05-22, 09:02 AM - EDT]]<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/File:POSSE_IRC_2017-05-20T09-02-EDT.txtFile:POSSE IRC 2017-05-20T09-02-EDT.txt2017-05-22T14:00:51Z<p>Stoney.jackson: Minutes from a POSSE IRC meeting on May 20, 2017.</p>
<hr />
<div>Minutes from a POSSE IRC meeting on May 20, 2017.</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_2_ActivitiesStage 2 Activities2017-04-20T22:18:19Z<p>Stoney.jackson: /* Downloads */</p>
<hr />
<div>= 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 POSSE Stage 3<br />
<br />
= Schedule April 2017 POSSE =<br />
<br />
Below is the schedule for the during-workshop activities. <br />
<br />
{| class="wikitable"<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 />
| Welcome to Google - Cat Allman, Senior Manager, Google Open Source Program Office <br />
| All<br />
|-<br />
| 2:15 <br />
| 1.1 Welcome<br />
* Plan for the day<br />
* Welcome to San Francisco<br />
* Introducing everyone<br />
* Workshop overview and schedule<br />
| Greg, Lori<br />
|-<br />
| 3:00<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 />
|Clif, Heidi<br />
|-<br />
| 4:30<br />
| Break<br />
| All<br />
|-<br />
| 4:45<br />
| Sarah Novotny - Building Community<br />
| All<br />
|-<br />
| 5:15 <br />
| 1.3 HFOSS Process and Tools<br />
* How tools fit and support HFOSS culture<br />
* Upstream Adoption<br />
* Licensing - Tom Callaway<br />
| Stoney, Tom<br />
|-<br />
| 5:45<br />
| Dinner - working / social dinner<br />
| All<br />
|-<br />
| 6:45<br />
| 1.4 Git Intro Activity<br />
* [https://github.com/StoneyJackson/git-intro-activity Hands-on exploration] of managing a local repository <br />
| Stoney, Darci<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:30<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:00<br />
| Leave the Hotel for Google<br />
| All<br />
|-<br />
| 8:30<br />
| Google OSPO - Cat Allman, Senior Manager, Google Open Source Program Office <br />
| <br />
|-<br />
| 8:45<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 />
| Stoney, Darci<br />
|-<br />
| 10:45 <br />
| Break<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 />
| Clif, Heidi<br />
|-<br />
| 12:00<br />
| Lunch <br />
| All<br />
|-<br />
| 1:00<br />
| Student Experience as Contributors and Open Source Clubs<br />
| Matt<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 />
| Clif, Heidi<br />
|-<br />
| 2:35<br />
| 2.5 Project Evaluation Activity<br />
* Review critical criteria for a chosen project<br />
* Go through secondary criteria for chosen project (if time permits)<br />
| Greg, Darci<br />
|-<br />
| 3:15<br />
| Break - Tour of Google<br />
| All<br />
|-<br />
| 4:00<br />
| 2.6 Planning for HFOSS Participation<br />
* Form groups (based either on courses or HFOSS projects)<br />
* In each group:<br />
** Identify three things that you would like to get done by the end of POSSE<br />
** Plan a schedule for accomplishing these<br />
| Lori<br />
|-<br />
| 5:30 <br />
| Return to the hotel and Dinner <br />
| All<br />
|- <br />
|<br />
! Day 3<br />
|<br />
|-<br />
| 7:45<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:15<br />
| Note: Meeting will be at the hotel <br />
3.1 Understanding POSSE Stage 3<br />
* Experience reports<br />
| Greg, Becka, Cam<br />
|-<br />
| 9:15 <br />
| <br />
3.2 Sharing HFOSS Learning Activities<br />
* Review of Activity Template<br />
* Group work<br />
| Heidi<br />
|-<br />
| 10:15<br />
| Break<br />
| All<br />
|-<br />
| 10:30<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
| All<br />
|-<br />
| 11:15<br />
| Lunch<br />
| All<br />
|-<br />
| 12:30<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* Groups report back on work done before lunch<br />
* Groups continue to work <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 />
| Lori, Greg<br />
|-<br />
| 1:45<br />
| 3.4 Going Forward<br />
* Evaluation form<br />
* Open discussion <br />
* Closing remarks<br />
| Greg<br />
|-<br />
| 2:00<br />
| End - BART to airport<br />
| All<br />
|}<br />
<br />
= Downloads =<br />
Presentation materials for stage 2: https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8<br />
<br />
= Pads & Shared Drives =<br />
<br />
* Google Drive folder for team activities<br />
** https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8?usp=sharing<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 />
[[Category:Instructor Activities]]<br />
[[Category:POSSE]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Talk:IRC_Meeting_2Talk:IRC Meeting 22017-03-30T20:14:47Z<p>Stoney.jackson: Request to fix link.</p>
<hr />
<div>http://www.irchelp.org/irchelp/irctutorial.html is a broken link. Maybe this is the right one: http://www.irchelp.org/ . Couldn't edit that part. So leaving a note here.</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Stage_1_ActivitiesStage 1 Activities2017-02-27T14:37:31Z<p>Stoney.jackson: Add Copyright and Licensing activity</p>
<hr />
<div>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 Heidi Ellis (ellis@wne.edu). <br />
<br />
=== Part A: Due Mar 13th ===<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 Mar 13th, 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: Due Apr 4th ===<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 />
# '''[[Evaluate a Project (Activity)]]''' - 60-90 minutes - Post results to wiki <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 Apr 3rd, 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: Due Apr 19th ===<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 Apr 17th (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 />
<br />
[[Category:POSSE]]<br />
[[Category:Instructor Activities]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Copyright_and_Licensing_(Activity)Intro to Copyright and Licensing (Activity)2017-02-18T23:24:54Z<p>Stoney.jackson: Improve formatting</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Copyright and Licensing (Activity)<br />
|overview=<br />
Participants will explore different types of licenses frequently used by open source projects.<br />
|prerequisites=<br />
None<br />
|objectives=<br />
* Identify a project’s license<br />
* Identify constraints license imposes on your contributions<br />
* Articulate whether or not you are comfortable contributing to a project with a given license<br />
|process skills=<br />
* Critical Thinking<br />
* Communication<br />
}}<br />
<br />
=== Background ===<br />
<br />
A quick YouTube search will yield a number of good videos on copyright and licensing. I recommend watching one or two on each topic: copyright and licensing. Here are a few of our favorites.<br />
<br />
* Copyright Clearance Center. “Copyright Basics”. 2010. https://youtu.be/Uiq42O6rhW4 . This video explains copyrights from a business perspective.<br />
* Intel Software. “Open Source Basics”. 2014. https://youtu.be/Tyd0FO0tko8 . This video explains how open source software is enabled through licensing.<br />
* Watch Now, UK. “Creative Commons & Copyright Info”. 2012. https://youtu.be/8YkbeycRa2A This video explains the purpose of licenses from a content producer’s view who wants to let other use their work without having to ask permission. It specifically talks about the Creative Commons licenses.<br />
* CppCon 2015: Kevin P. Fleming “A Crash Course in Open Source Licensing". https://youtu.be/cJIi-hIlCQM . A much more in-depth, longer talk on copyright, software, and open source licensing.<br />
<br />
=== Directions ===<br />
<br />
# Identify the license for the following projects:<br />
#* https://github.com/openmrs/openmrs-core<br />
#* https://github.com/apache/incubator-fineract <br />
#* https://github.com/regulately/regulately-back-end<br />
# Go to https://tldrlegal.com/ . Look up each of the above licenses. Identify the “cans” the “cannots” and the “musts” for each.<br />
# For each license, state whether you would (or would not) be comfortable contributing code to that project and why (or why not).<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section answering the above questions.<br />
<br />
= Notes for Instructors =<br />
<br />
<br />
=== Assessment ===<br />
<br />
<br />
=== Comments ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''<br />
|difficulty=<br />
Easy to medium<br />
|time=<br />
40-60 minutes<br />
|environment=<br />
Internet access<br />
|author=<br />
Stoney Jackson and Karl Wurst<br />
|source=<br />
|license=<br />
''{{License CC BY SA}}''<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
--------------------<br />
[[Category:Learning Activity]]<br />
[[Category:Culture_and_Intellectual_Property]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Copyright_and_Licensing_(Activity)Intro to Copyright and Licensing (Activity)2017-02-18T23:19:59Z<p>Stoney.jackson: Initial post</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
''Intro to Copyright and Licensing (Activity)''<br />
|overview=<br />
''Participants will explore different types of licenses frequently used by open source projects.''<br />
|prerequisites=<br />
''None''<br />
|objectives=<br />
''* Identify a project’s license<br />
* Identify constraints license imposes on your contributions<br />
* Articulate whether or not you are comfortable contributing to a project with a given license<br />
''<br />
|process skills=<br />
''Analysis and reflection''<br />
}}<br />
<br />
=== Background ===<br />
<br />
A quick YouTube search will yield a number of good videos on copyright and licensing. I recommend watching one or two on each topic: copyright and licensing. Here are a few of our favorites.<br />
<br />
* Copyright Clearance Center. “Copyright Basics”. 2010.<br />
https://youtu.be/Uiq42O6rhW4 .<br />
This video explains copyrights from a business perspective.<br />
* Intel Software. “Open Source Basics”. 2014.<br />
https://youtu.be/Tyd0FO0tko8 .<br />
This video explains how open source software is enabled through licensing.<br />
* Watch Now, UK. “Creative Commons & Copyright Info”. 2012.<br />
https://youtu.be/8YkbeycRa2A<br />
This video explains the purpose of licenses from a content producer’s view who wants to let other use their work without having to ask permission. It specifically talks about the Creative Commons licenses.<br />
* CppCon 2015: Kevin P. Fleming “A Crash Course in Open Source Licensing".<br />
https://youtu.be/cJIi-hIlCQM<br />
A much more in-depth, longer talk on copyright, software, and open source licensing.<br />
<br />
=== Directions ===<br />
<br />
# Identify the license for the following projects:<br />
#* https://github.com/openmrs/openmrs-core<br />
#* https://github.com/apache/incubator-fineract <br />
#* https://github.com/regulately/regulately-back-end<br />
# Go to https://tldrlegal.com/ . Look up each of the above licenses. Identify the “cans” the “cannots” and the “musts” for each.<br />
# For each license, state whether you would (or would not) be comfortable contributing code to that project and why (or why not).<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section answering the above questions.<br />
<br />
= Notes for Instructors =<br />
<br />
<br />
=== Assessment ===<br />
<br />
<br />
=== Comments ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''<br />
|difficulty=<br />
''Easy to medium''<br />
|time=<br />
''40-60 minutes''<br />
|environment=<br />
''Internet access''<br />
|author=<br />
''Stoney Jackson and Karl Wurst''<br />
|source=<br />
''''<br />
|license=<br />
''<nowiki>{{License CC BY SA}}</nowiki>''<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
--------------------<br />
[[Category:Learning Activity]]<br />
[[Category:Culture_and_Intellectual_Property]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2017-02-04T16:03:25Z<p>Stoney.jackson: /* Deliverables: */</p>
<hr />
<div>__NOTOC__<br />
{| border="1"<br />
|- <br />
|'''Title''' ||Bug Trackers<br />
|-<br />
|'''Overview''' || 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 />
|- <br />
|'''Prerequisite Knowledge''' || None<br />
|-<br />
|'''Learning Objectives''' || Ability to: 1) Describe the role that a bug tracker plays in a FOSS project, 2) Describe the different types of issues stored in a bug tracker and their priorities, and 3) Identify and track the status of a particular bug in a project. <br />
|}<br />
<br />
<br />
=== Background: ===<br />
Bug tracking systems are a form of change management and organization used by FOSS projects. Bug trackers do far more than simply keep track of bugs. They also are used to hold new feature requests, patches, and some tasks. Bug trackers are also called request trackers, issue trackers, request trackers and ticket systems. Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.<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 Wikipedia's page on Bug Tracking Systems]<br />
<br />
=== Directions: ===<br />
We will begin by looking at a typical Bugzilla instance for a project. We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team. <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 />
## Sev <br />
## Pri<br />
## OS <br />
## Product <br />
## Status <br />
## Resolution <br />
## Summary <br />
# Describe how you discovered the definitions and how did you find 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 shading of some bug reports?<br />
# What is the meaning of the colors used when describing a bug (red, gray, black)?<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 />
## Identify when the bug was submitted.<br />
## Identify if there has been recent discussion 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 />
# 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 contributors of patches?<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 “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 />
POSSE: On your user wiki page, a section describing the results of your exploration below.<br />
<br />
= Notes for Instructors =<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 />
How will the activity be graded?<br />
<br />
How will learning will be measured?<br />
<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 />
What should the instructor know before using this activity?<br />
<br />
What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
<br />
=== Additional Information: ===<br />
{| border="1"<br />
|- <br />
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]<br />
|-<br />
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf<br />
|-<br />
|'''Level of Difficulty''' || Easy<br />
|-<br />
|'''Estimated Time to Completion''' || 60 Minutes<br />
|-<br />
|'''Materials/Environment''' || Access to Internet/Web and web browser. <br />
|-<br />
|'''Author''' || Heidi Ellis<br />
|-<br />
|'''Source''' || None.<br />
|}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
{{License CC BY SA}}<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:CS Principles]]<br />
[[Category:CS2]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/FOSS_in_Courses_1_(Instructors)FOSS in Courses 1 (Instructors)2017-02-04T15:47:24Z<p>Stoney.jackson: /* Deliverables */</p>
<hr />
<div>__NOTOC__<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''Title''' || FOSS In Courses<br />
|-<br />
| '''Overview''' || 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 />
|- <br />
| '''Prerequisite Knowledge''' || An understanding of the course in which students will be involved in a FOSS project.<br />
|-<br />
| '''Learning Objectives''' || Ability to: <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 />
|}<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 [http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/ 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/index.php/Teaching_Materials_Catalogue 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 />
## Steve Jacobs at RIT has a [http://teachingopensource.org/index.php/RIT/The_Course Open Source Course].<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 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 />
How will the activity be graded?<br />
<br />
How will learning will be measured?<br />
<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 />
<br />
What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Additional Information ===<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]<br />
|-<br />
| '''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf<br />
|-<br />
| '''Level of Difficulty''' || Is this activity easy, medium or challenging? <br />
|-<br />
| '''Estimated Time to Completion''' || 60-90 minutes<br />
|-<br />
| '''Materials/Environment''' || Access to Internet/Web and web browser.<br />
|-<br />
| '''Author''' || Who wrote this activity? <br />
|-<br />
| '''Source''' || <br />
|-<br />
| '''License''' || Licensed 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 />
{{License CC BY SA}}<br />
<br />
[[Category:Instructor Activities]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Evaluate_a_Project_(Activity)Evaluate a Project (Activity)2017-02-04T15:45:37Z<p>Stoney.jackson: /* Deliverables: */</p>
<hr />
<div>__NOTOC__<br />
{| border="1"<br />
|- <br />
|'''Title''' || Project Evaluation Activity<br />
|-<br />
|'''Overview''' || Learners will gain an understanding of the breadth of available HFOSS projects. Learners will also gain an understanding of the identifying characteristics of HFOSS projects including pattern of contributions, patterns of commits, programming languages used, and more. <br />
|- <br />
|'''Prerequisite Knowledge''' || Completion of Browsing a Forge Activity or understanding of SourceForge and OpenHub; Understanding of the course in which students will be participating in an HFOSS project.<br />
|-<br />
|'''Learning Objectives''' || Ability to identify likely HFOSS projects. <br />
|}<br />
<br />
<br />
=== Background: ===<br />
This activity is intended to give you an overview of what to consider when evaluating an HFOSS project for student participation and for you to gain experience using the rubric.<br />
<br />
=== Directions: ===<br />
====Walk through of an evaluation of the OpenMRS project.====<br />
There are many criteria which should be looked at when determining if a project is appropriate to use in your class. These criteria are broken into two groups - mission critical and secondary. For this exercise, the secondary criteria is optional.<br />
:'''Mission Critical Criteria-Viability'''<br />
<br />
#Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complex.<br />
##Go to the OpenMRS web page (http://openmrs.org/), scroll to the bottom and choose ''OpenMRS Wiki'' (under ''Other OpenMRS sites''). From the menu on the left expand the ''Developer Guide'' and the ''Getting Started as a Developer'' options and then choose ''Technical Overview''. From examination of the technology stack, the architecture looks modular and further search shows it is documented elsewhere on the site. This provides a first look at the complexity of the application and the number and various different technologies involved.<br />
##Based upon the results from OpenHub (gathered in the FOSS Field Trip activity) and the information from the OpenMRS Technical Overview page, think about the size of the code base and how many different technologies and layers are involved in the application. What would you score this project for size/scale/complexity on a scale of one to three where one is "low" and three is "high". <br />
#Activity - To support student participation a project should be reasonably active. Number of commits can be used as an indicator of activity. <br />
##Based upon the number of commits (gathered in the FOSS Field Trip activity) would you consider this project active? Why or why not?<br />
#Community - A suitable project has an active user community. While it is difficult to quantitatively evaluate the activity of a user community, some indicators include a regular history of project downloads and documentation updates over time, current activity on user mailing lists, and testimonials on the project web site.<br />
##Examine download activity<br />
###Go to [http://sourceforge.net/ sourceforge.net] and enter OpenMRS into the search box. <br />
###Choose OpenMRS from the search results.<br />
###Click on the number of downloads that is listed on the project page.<br />
###Change the date range to give a graph of downloads over the last year. <br />
##OpenMRS has begun migrating legacy mailing list activity to OpenMRS Talk. Examine [https://talk.openmrs.org/ discussion] activity<br />
##Examine the [https://botbot.me/freenode/openmrs/ IRC logs]<br />
##Based upon the download history, discussion activity, and IRC activity, do you feel this project has a good community? Why or why not?<br />
<br />
<br />
:'''Mission Critical Criteria-Approachability'''<br />
<br />
:Here you are evaluating a project's on-ramp to contribution, scoring as follows:<br />
<br />
::1-Insufficient-Few or no pointers on how to become involved.<br />
<br />
::2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.<br />
<br />
::3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.<br />
<br />
#Examine project on-ramp.<br />
##Link to getting started - The website has a [http://openmrs.org/help/ Get Involved page] with links to ways you can contribute and share your ideas. <br />
##Each of the links (Develop, Test, Document, Translate) contain more detailed information about what and how you can contribute. <br />
##The [https://wiki.openmrs.org/display/docs/Getting+Started+as+a+Developer Getting Started as a Developer] page contains a detailed list of how to get started including a list of introductory issues.<br />
##Detailed instructions - The [https://wiki.openmrs.org/display/docs/Developer+Guide Developer Guide] contains instructions and information in many areas including process, architecture, tools, and developer documentation.<br />
##Based upon the resources you looked at, how would you rate the approachability of the OpenMRS project? <br />
<br />
<br />
:'''Mission Critical Criteria-Suitability'''<br />
#Appropriate Artifacts - Since evaluation is dependent on class objectives, in this example we'll assume the objective is to learn the process of working in an authentic development environment by contributing bug fixes to OpenMRS.<br />
##Opportunities to contribute bug fixes - Examine the issues found at the bottom of the [https://wiki.openmrs.org/display/docs/Getting+Started+as+a+Developer getting started as a developer page]. How are the introductory issues categorized? How many issues are listed?<br />
##Documentation on how to contribute bug fixes - On the [https://wiki.openmrs.org/display/docs/Tickets Tickets page] there is information on how to create and work on an issue, including links to coding standards and the code submission process. Review this information.<br />
##Based upon the number of bugs suitable for students to tackle and information on the process of how to submit bug fixes, do you think this would be an appropriate project for your students? Why or why not?<br />
#Contributor Support - Does the project have a high volume of guidance to help students as they learn?<br />
##Communication Tools - Communication tools are directly available from any of the Wiki Spaces (Documentation, Projects, Resources). The [https://wiki.openmrs.org/display/RES/Home Resources page] contains links to OpenMRS Talk and IRC Chat, as well as links to group meetings (under Events), and training opportunities. <br />
##Web Presence - Examine the [https://botbot.me/freenode/openmrs/ IRC logs]. Has there been activity during the last week? <br />
##Operating Processes - Links to information about coding standards, the code submission process, and commit privileges can be found on the [https://wiki.openmrs.org/display/docs/How-To+Submit+Code How-To Submit Code page]. The process for making feature requests is available on the [https://wiki.openmrs.org/display/docs/Tickets Tickets page]. Are these processes well documented?<br />
##Response to Questions - Review a few of the posts on the OpenMRS [https://talk.openmrs.org/ discussion platform]. Do posts to this forum receive timely and supportive responses?<br />
##How would you rate the support that newcomers to OpenMRS receive?<br />
<br />
<br />
:'''On your wiki page, write a summary of why you think the OpenMRS project would be suitable for your course. Be sure to include information about the course and reasons why OpenMRS would be a good/poor match.<br />
<br />
<br />
:'''Overall evaluation for Mission Critical criteria''' - If the mission-critical criteria seemed reasonable, then you may want to evaluate the following secondary criteria. If the mission-critical was not reasonable then the project would not be considered suitable for student participation.<br />
<br />
<br />
:'''Secondary Criteria-Viability - Secondary criteria sections are OPTIONAL for the POSSE workshop assignment'''<br />
#Domain<br />
##Does this project require domain knowledge that may be difficult for students to learn? OpenMRS is a medical records system. Students should be able to grasp it well enough to contribute a bug fix, which is the learning objective assumed in this example.<br />
##How would you rate the understandability of OpenMRS?<br />
#Maturity<br />
##To have the organization support student learning, the project should have at least one stable production release. The [https://wiki.openmrs.org/display/RES/Platform+Release+Notes Platform Release Notes page] lists releases. <br />
##Does OpenMRS have enough of a stable base to support student learning? Why or why not?<br />
#User Support <br />
##The project should have clear instructions for downloading, installing, and using the project. As noted previously, the [https://wiki.openmrs.org/display/docs/Getting+Started+as+a+Developer Getting Started as a Developer page] provides detailed information about setting up and using the required tools, in addition there are detailed instructions related to installation, configuration, system requirements, and troubleshooting, including videos.<br />
##Does the documentation seem sufficient for getting students started?<br />
#Roadmap <br />
##Student learning is best supported by projects that have a roadmap that includes new feature development, a method for users to submit new feature requests and a process for identifying how new features are prioritized. Feature requests are made through JIRA, the OpenMRS issue tracker. Road map planning and the process for prioritizing feature requests is available on the [https://wiki.openmrs.org/display/docs/Technical+Road+Map+Planning Technical Roadmap Planning page]. Here you will find information about the planning process and how to participate in the planning process. The [https://wiki.openmrs.org/display/docs/Technical+Road+Map Technical Road Map page] identifies features, their current status, and a point of contact, in addition to expected dates of completion. <br />
##Does the roadmap provide you with enough information to make a decision about using it in your course?<br />
<br />
<br />
:'''Secondary Criteria-Approachability - Secondary criteria sections are OPTIONAL for the POSSE workshop assignment'''<br />
#Contribution Types<br />
##Does the project contain opportunities for multiple types of contribution and of the type that fits the class? There are multiple projects for testers, tech writers, and developers. These can be seen on the [http://openmrs.org/help/ Get Involved page]. Are the number of and type of bugs available suitable for students given your course and the class size? Are there other ways that students could contribute?<br />
#Openness to Contributions<br />
##Acceptance of a student contribution to a project provides valuable affirmation to student learning. Determine whether the project accepts student patches. The process for contribution is documented on the [https://wiki.openmrs.org/display/docs/Tickets Tickets page]. Does this project seem likely to accept student contributions?<br />
#Student Friendliness<br />
## Do community members moderate the tone of communication? Review the discussion platform and IRC to gauge tone. Review the [https://talk.openmrs.org/ discussion platform] and [https://botbot.me/freenode/openmrs/ IRC logs]. What was the tone of the communication?<br />
<br />
<br />
:'''Secondary Criteria-Suitability - Secondary criteria sections are OPTIONAL for the POSSE workshop assignment'''<br />
#Project Description<br />
##Students must be able to understand the purpose of the project. Does the project clearly describe the product? Can students understand the intended uses of the product? - The [http://openmrs.org/about/ About page] provides an overview of who, where, and what OpenMRS is, including a downloadable PDF file and a video. <br />
#Platform<br />
##What software and hardware platform does the FOSS project run on? Development environment can be built on Windows, Linux or Mac OS X completely with FOSS software. (Project development information found [https://wiki.openmrs.org/display/docs/Step+by+Step+Installation+for+Developers here])<br />
##Are there resources to support these platforms?<br />
##Are students familiar with the platforms?<br />
#Development Features - Is the class dependent on specific development features? (Project development information found [https://wiki.openmrs.org/display/docs/Step+by+Step+Installation+for+Developers here])<br />
##Programming language - What is the primary language?<br />
##Development environment - What environments are supported? <br />
##Supporting technologies - What technologies are suggested/required?<br />
<br />
=== Deliverables: ===<br />
<br />
POSSE: On your user wiki page, a section describing your evaluation of OpenMRS as a suitable project for your course.<br />
<br />
= Notes for Instructors =<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 />
How will the activity be graded?<br />
<br />
How will learning will be measured?<br />
<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 />
What should the instructor know before using this activity?<br />
<br />
What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Variants and Adaptations: ===<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]] at UPenn in his [[FOSS_Course_Syllabus|Full FOSS Course]]<br />
<br />
=== Additional Information: ===<br />
A list of projects that may be of interest can be found at:<br />
[http://www.foss2serve.org/index.php/HFOSS_Projects List of HFOSS projects]<br />
<br />
Read the [http://foss2serve.org/images/foss2serve/a/ac/Evaluating_FOSS_Projects.docx SIGCSE paper on evaluating FOSS projects]<br />
<br />
Or 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 />
<br />
{| border="1"<br />
|- <br />
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]<br />
|-<br />
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf<br />
|-<br />
|'''Level of Difficulty''' || Is this activity easy, medium or challenging? <br />
|-<br />
|'''Estimated Time to Completion''' || 60-90 minutes <span style="color:#FF0000">This activity can take a significant amount of time. We only expect you to spend 60-90 minutes exploring.</span> You may not complete the activity within this time. Of course you are welcome to spend more time if you wish.<br />
|-<br />
|'''Materials/Environment''' || Access to Internet/Web and web browser, [[Media:Evaluating_FOSS_Projects.docx | SIGCSE paper on evaluating FOSS projects]], [http://www.foss2serve.org/images/foss2serve/0/0c/Blank_Evaluation_Template.xlsx Blank evaluation template referred to in the SIGCSE paper]<br />
|-<br />
|'''Author''' || Michele Purcell<br />
|-<br />
|'''Source''' || N/A<br />
|-<br />
|'''License''' || Licensed CC BY-SA <br />
|}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
--------------------<br />
This work is licensed under a <br />
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]<br />
<br />
[[File:CC_license.png]]<br />
<br />
<br />
[[Category: Learning_Activity]]<br />
[[Category:Use_and_Evaluate]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_FOSS_Project_Anatomy_(Activity)Intro to FOSS Project Anatomy (Activity)2017-02-04T15:41:02Z<p>Stoney.jackson: /* Deliverables: */</p>
<hr />
<div>__NOTOC__<br />
{| border="1"<br />
|- <br />
|'''Title''' || Project Anatomy Activity<br />
|-<br />
|'''Overview''' || Learners will gain a high level familiarity with the structure, processes, and tools used in FOSS projects.<br />
|- <br />
|'''Prerequisite Knowledge''' || None<br />
|-<br />
|'''Learning Objectives''' || Upon completion of this activity, a student will be able to: 1) Identify high-level components of and terminology associated with a HFOSS project, 2) Discuss that implementation process and tools can vary from project to project.<br />
|}<br />
<br />
<br />
=== Background: ===<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 />
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: [http://en.wikipedia.org/wiki/Revision_control Wikipedia page on revision 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. <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. Summarize the roles that you think would be most applicable for your students on your faculty wiki page. If you think that more than a single role is applicable, indicate why. What are the commonalities across roles? What are the differences? <br />
<br />
'''Tracker --''' An overview of the Sugar Labs bug tracker may be found [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems here]. The Sugar Labs bug tracker can be found [http://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&order=priority here]. On your wiki page describe the general process for submitting a bug and indicate the types/categories of tickets listed on this page as well as the information available for each ticket.<br />
<br />
'''Repository --''' http://git.sugarlabs.org/sugar-base<br />
Scan the "Activities" section on the repository and determine the date of last "Commit" (an update of the repository). Place your answer on your wiki page.<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]. Include an entry on your wiki page that describes 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: http://meeting.sugarlabs.org/ & http://chat.sugarlabs.org/ <br />
* Mailing lists: http://lists.sugarlabs.org/<br />
* Blog: http://planet.sugarlabs.org/<br />
* Wiki: http://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki<br />
<br />
<br />
'''''The Sahana Eden Project (http://eden.sahanafoundation.org/wiki)'''''<br />
<br />
Read the information found [http://eden.sahanafoundation.org/wiki here] to get an overview of the goals of the project and the types of contributions one can make.<br />
<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. Follow the links to each of the groups listed below and summarize the information you find there on your faculty wiki page. For example, are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?<br />
* Developers <br />
* Testers<br />
* Designers<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 --''' http://eden.sahanafoundation.org/wiki/InstallationGuidelines<br />
The installation guidelines begin [http://eden.sahanafoundation.org/wiki/InstallationGuidelines here] with the option to specify your operating system. For this exercise, choose '''Linux''', then '''Developer''', and finally '''Manually'''. At the bottom on the page click '''InstallationGuidelines/Developer/PostPython'''. <br />
<br />
'''Release cycle --''' Information about Sahana Eden's release cycle and roadmap can be found [http://eden.sahanafoundation.org/roadmap here]. Include an entry on your wiki page that describes the information you find here.<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/doku.php/community:mailing_lists#sahana-discuss (wider discussion list for issues relating to the wider Sahana ecosystem)<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 />
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 />
How will the activity be graded?<br />
<br />
How will learning will be measured?<br />
<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 />
What should the instructor know before using this activity?<br />
<br />
What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Variants and Adaptations: ===<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]] at UPenn in his [[FOSS_Course_Syllabus|Full FOSS Course]]<br />
<br />
=== Additional Information: ===<br />
{| border="1"<br />
|- <br />
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]<br />
|-<br />
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf<br />
|-<br />
|'''Level of Difficulty''' || Is this activity easy, medium or challenging? <br />
|-<br />
|'''Estimated Time to Completion''' || 60 Minutes<br />
|-<br />
|'''Materials/Environment''' || Access to Internet/Web and web browser. <br />
|-<br />
|'''Author''' || Who wrote this activity? <br />
|-<br />
|'''Source''' || N/A<br />
|-<br />
|'''License''' || Licensed CC BY-SA<br />
|}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
--------------------<br />
This work is licensed under a <br />
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]<br />
<br />
[[File:CC_license.png]]<br />
<br />
[[Category: Learning_Activity]]<br />
[[Category:Introduction]]<br />
<br />
[[Category: CS Principles]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_Wiki_(Activity)Intro to Wiki (Activity)2017-02-04T15:38:52Z<p>Stoney.jackson: /* Deliverables */</p>
<hr />
<div>__NOTOC__<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''Title''' || Wiki Activity<br />
|-<br />
| '''Overview''' || Provides an overview of wikis and teaches basic skills for creating and editing wiki pages. <br />
|- <br />
| '''Prerequisite Knowledge''' || None.<br />
|-<br />
| '''Learning Objectives''' || Upon completion of this activity, students will be able to: 1) Describe typical uses of wikis, 2) Create and edit a wiki page, 3) Discuss use of wikis in FOSS projects.<br />
|}<br />
<br />
=== Background ===<br />
<br />
According to Wikipedia: "A wiki is a website which allows its users to add, modify, or delete its content via a web browser usually using a simplified markup language or a rich-text editor. Wikis are powered by wiki software. Most are created collaboratively." [http://en.wikipedia.org/wiki/Wiki]<br />
<br />
<br />
'''The Need for Web publishing'''<br />
* Quick publication via the Web<br />
* Decentralized control<br />
** But room for recovery<br />
* Web page creation without HTML knowledge<br />
<br />
'''The Solution - Wikis'''<br />
* Access via a Web browser<br />
* Simple text editor<br />
* Character based formatting<br />
* Built-in change tracking and roll-back<br />
<br />
'''Wiki History'''<br />
* Predecessors<br />
** Memex, hypertext, hypercards<br />
* Wiki Wiki Web - 1994<br />
** Ward Cunningham <br />
* Today: Lots of Wiki systems<br />
** Major platforms include: Media Wiki, Docuwiki, Tikiwiki, MoinMoin<br />
** Wiki text syntax is generally similar across platforms but with enough variation to be confusing<br />
** Wiki Creole attempts to provide a standard but has not been completely adopted<br />
<br />
For our learning activity we will focus on Media Wiki, the wiki software that powers Wikipedia. <br />
<br />
=== Directions ===<br />
<br />
==== Part 1 - Introduction to Wikis ====<br />
<br />
# Read the overview [http://en.wikipedia.org/wiki/Wiki article] about wikis. (After all, what starting point can there be for wikis other than the Wikipedia article?)<br />
# Read basics of MediaWiki page [http://www.mediawiki.org/wiki/Help:Starting_a_new_page creation] and page [http://www.mediawiki.org/wiki/Help:Contents editing]<br />
<br />
==== Part 2 - Creating a wiki page ====<br />
<br />
As part of your introduction to other POSSE participants, please create a short bio page for yourself in foss2serve.org.<br />
Do the following:<br />
# Go to the [http://www.foss2serve.org Foss2serve] wiki.<br />
# Login and change your password. You should have received a user ID and temporary password by email. If you did not, please contact Greg Hislop at hislop@drexel.edu.<br />
# Create a new "User" page in the wiki for your user ID. You can see an example [[User:Hislop | here]] and begin to create your page by modifying the URL of this example, changing the user ID to your own user ID.<br />
# Edit the participants page for this POSSE and add your own name and link your name to the User page you created in the prior step. Please keep the names in alphabetic order by last name. In a later activity, you will create a blog and add the link to your blog here too. The participants page is [[POSSE_2016-11_Participants | here]]<br />
<br />
POSSE participants: You will be asked to contribute to this wiki page during future activities.<br />
<br />
==== Part 3 - Wiki Examples ====<br />
<br />
# Browse several example wikis and try to define the role that they play. Starting points:<br />
* '''Wikipedia''' is most widely known and used wiki. With over 4 million articles, it can be overwhelming. On the other hand, it contains lots of material about writing wiki pages, organizing wikis, managing large wikis, and using advanced features of MediaWiki. You might browse by starting at http://en.wikipedia.org/wiki/Wikipedia:About<br />
* '''[https://fedoraproject.org/wiki/Fedora_Project_Wiki The Fedora Project Wiki]''' is an example of a relatively large wiki used to support a FOSS project. The wiki provides a home for much of the technical documentation, and other materials related to operation of the Fedora project.<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: A foss2serve user wiki page created with brief bio. Include a link to your blog if you have one.<br />
<br />
A wiki page with a short biography and (in a later assignment) a link to your blog<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 (possible rubrics for student assignment) ===<br />
'''Below are the questions that need to be answered to provide assessment for this activity along with a sample assessment table.'''<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 />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
Comments to instructor using this activity with students:<br />
* Some discussion with students about wiki etiquette may be helpful.<br />
* Part 2 will need to be modified with instructions for an outside wiki.<br />
<br />
=== Additional Information: ===<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''ACM Knowledge Area/Knowledge Unit''' || Social Issues and Professional Practice [[ACM_Body_of_Knowledge]]<br />
|-<br />
| '''ACM Topic''' || Unclear - https://www.acm.org/education/CS2013-final-report.pdf<br />
|-<br />
| '''Level of Difficulty''' || Easy<br />
|-<br />
| '''Estimated Time to Completion''' || 30 minutes<br />
|-<br />
| '''Materials/Environment''' || Access to the Web via a web browser. <br />
|-<br />
| '''Author''' || Greg Hislop <br />
|-<br />
| '''Source''' || <br />
|-<br />
| '''License''' || Licensed 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 />
--------------------<br />
{{License CC BY SA}}<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:CS Principles]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Teaching_Open_Source_(Activity)Teaching Open Source (Activity)2017-02-04T15:34:35Z<p>Stoney.jackson: /* Deliverables */</p>
<hr />
<div>__NOTOC__<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''Title''' || TOS Activity<br />
|-<br />
| '''Overview''' || Learners will become members of the Teaching Open Source mailing list and gain some familiarity with the TOS wiki <br />
|- <br />
| '''Prerequisite Knowledge''' || None.<br />
|-<br />
| '''Learning Objectives''' || A student will be able to: 1) Describe the TOS list and site<br />
|}<br />
<br />
<br />
=== Background ===<br />
<br />
Teaching Open Source is the primary website for academics interested in open source and involving their students in open source projects. TeachingOpenSource.org was set up in March 2009. The goal of the site is to foster collaboration and members are both academics and industry leaders.<br />
<br />
'''''NOTE: Over the years, the TOS wiki has been uncontrolled and heavily spammed. There is currently a project in process to rebuild the wiki and bring it under administrative control. Because of that, we are using an alternative version of Part 2 below that does not require editing the TOS wiki. - 2016-09-16 '''''<br />
<br />
=== Directions ===<br />
<br />
==== Part 1 - Joining the Teaching Open Source Mailing List ====<br />
<br />
Teaching Open Source (TOS)- http://teachingopensource.org/index.php/Main_Page - is a "neutral collaboration point for professors, institutions, communities, and companies to come together and make the teaching of Open Source a global success." You will visit this site and sign up for the list serv. <br />
<br />
Do the following:<br />
# Go to: http://teachingopensource.org/index.php/Main_Page<br />
# Locate the '''Get Involved''' section.<br />
# Click the '''Join the mailing list''' link.<br />
# Read through the information on the resulting page. Click the '''mailing list''' link.<br />
# Complete the information in the form and click the '''Subscribe''' button.<br />
<br />
<!-- Hidden at present because the TOS wiki is under re-construction<br />
==== Part 2 - Adding Yourself to the People Page on Teaching Open Source ====<br />
<br />
One tool used by members of the open source world is wiki pages. During this part of the activity you will participate in the TOS community by creating a wiki page and introducing yourself to the community.<br />
# Go to: http://teachingopensource.org/index.php/Main_Page<br />
# Locate the '''Get Involved''' section.<br />
# Click the '''Add yourself to the roll call''' link.<br />
# Read through the page and see how people describe themselves on this page.<br />
# Locate '''Heidi Ellis''' in the roll call. <br />
# As you are looking at the entries in the roll call, notice that many of them include a link to google’s recaptcha mailhide. This link is what allows some of the emails to be hidden on the site and only be shown by using the captcha. The goal of this is to help reduce spam. <br />
## Instructions for setting up a recaptcha using google are located here: http://www.cmu.edu/cms//using-cms/add-content/embed-media/recaptcha.html<br />
# Return to the top of the page and click the '''create an account''' link.<br />
# This will bring you to the page for editing the wiki. Read down to the '''Joining the Wiki''' section. <br />
# Click the '''create an account''' link.<br />
# Enter the captcha information and complete the information requested. After you submit, you will receive a confirmation email.<br />
# Once you have successfully logged in, you can edit the Wiki page to add yourself to the Roll Call. Click '''edit''' on the right side of '''Professors''' to edit this page to add yourself.<br />
# The format of your entry should be, '''your name, your email, your institution/company/project, and whatever information you believe to be relevant about your work.''' For example, '''<pre>Lori Postner, </pre><pre>[http://www.google.com/recaptcha/mailhide/d?k=01Rtfg9ZLZQjNmYicvEWSQfA==&c=KlmpA7OQR5-G_yA7RRSa_-yALTitdnnlyUB1Yg2y234= Email Address via reCAPTACH&trade; Mailhide] </pre><pre>Associate Professor at [http://www.matcmp.ncc.edu/~postnel Nassau Community College], </pre><pre>I am working with the foss2serve team to learn how to incorporate HFOSS into my Computer Science courses.</pre>''' Your entry should begin with an asterisk (*) <br />
# Click '''Save'''.<br />
--><br />
<br />
==== Part 2 - Exploring the TOS Wiki ====<br />
<br />
Wikis are a common tool in open source projects. At noted above, the TOS wiki is currently locked down for rebuilding. So we would like you to explore the site a bit but you will not be making any changes.<br />
<br />
# Go to the TOS homepage: [http://teachingopensource.org]<br />
# Using the top menu items select "People" and then "Roll Call"<br />
# Browse the list of TOS participants noting the mix of faculty members and open source project professionals<br />
# Locate a few people with HFOSS interests similar to your own<br />
<br />
=== Deliverables ===<br />
<br />
None (but, you should now be subscribed to the TOS mailing list)<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 />
<br />
How will learning will be measured?<br />
<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 />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
What should the instructor know before using this activity?<br />
<br />
What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
<br />
=== Additional Information ===<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]<br />
|-<br />
| '''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf<br />
|-<br />
| '''Level of Difficulty''' || Is this activity easy, medium or challenging? <br />
|-<br />
| '''Estimated Time to Completion''' || 20-30 minutes <br />
|-<br />
| '''Materials/Environment''' || Access to Internet/Web and web browser and email client. <br />
|-<br />
| '''Author''' || Who wrote this activity? <br />
|-<br />
| '''Source''' || [http://teachingopensource.org/index.php/Main_Page Teaching Open Source web site]<br />
|-<br />
| '''License''' || Licensed 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 />
--------------------<br />
{{License CC BY SA}}<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Intro_to_FOSS_(Activity)Intro to FOSS (Activity)2017-02-04T15:31:03Z<p>Stoney.jackson: /* Deliverables */</p>
<hr />
<div>__NOTOC__<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''Title''' || Intro to FOSS Activity<br />
|-<br />
| '''Overview''' || Learner will gain an introduction to FOSS, its philosophy, and how it might benefit students.<br />
|- <br />
| '''Prerequisite Knowledge''' || None<br />
|-<br />
| '''Learning Objectives''' || Upon completion of this activity, participants should be able to: 1) Describe two or three major events in the history of FOSS, 2) Describe several characteristics of the open source philosophy, and 3) Identify why student involvement in FOSS could help learning.<br />
|}<br />
<br />
=== Background ===<br />
<br />
Welcome to the exploration of Open Source Software! The goal of this activity is for you to become familiar with the roots and culture of Open Source Software. This activity is only intended to give you a first taste of FOSS culture and development, enough to use as a foundation for future learning.<br />
<br />
Additional reading:<br />
* [http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ The Cathedral and the Bazaar] by Eric Raymond<br />
* [http://teachingopensource.org/index.php/Practical_OSS_Exploration Practical Open Source Exploration text] developed by the TeachingOpenSource community<br />
<br />
=== Directions ===<br />
<br />
==== 1. Expectations ====<br />
<br />
Your experiences in participating in FOSS projects and having students involved in such projects may be quite different from a more traditional classroom experiences where the instructor knows the material at a detailed level and is able to answer all student questions. In contrast, learning within a FOSS project can be less predictable and the instructor may serve as a guide or coach rather than being the source of all expertise. The instructor may enable the student to learn on her own and from the community. <br />
<br />
The world of FOSS is large and complex. Producing a large software project is a complex and challenging process, especially for those unfamiliar with developing industrial software. Such development is often messy and has much more variability than typically found in the classroom. This messiness creates challenges to educating students within this environment, but also creates wonderful opportunities for learning. A large part of successfully navigating such an experience is understanding how the expectations for you as an instructor must change:<br />
<br />
'''Expectation 1:''' You as the instructor will not have all of the answers due to the size and complexity of projects. However, you will have maps and guideposts along the way to help you and your students find the answers. This ability to navigate a project while only having a partial understanding is known as being "productively lost". You may not know exactly where you are, but you will have the tools to find out. <br />
<br />
'''Expectation 2:''' You as the instructor may feel uncomfortable in being "productively lost". The concept of not knowing answers to many student questions can be a foreign one and many instructors find this initially unsettling. This feeling has been likened to being in a foreign land not knowing the language and customs. <br />
<br />
'''Expectation 3:''' You are not alone in this learning process. You will have a community of fellow educators and FOSS representatives to answer questions along the way. <br />
<br />
The goal of this workshop is to enable you to be "productively lost" within a project, where you may not have a full grasp of a project, but you have sufficient signposts for you to be able to navigate the project and ask appropriate questions.<br />
<br />
==== 2. Overview of FOSS ====<br />
<br />
The readings below provide an introduction to FOSS. The readings include a bit of history and information in the culture of FOSS. Eric Raymond's "The Cathedral and the Bazaar" is a classic reading in FOSS, but we've only included a few parts here. You may want to read the full article when you have time. Read each of the following:<br />
# [https://www.gnu.org/philosophy/free-sw.html The Free Software Definition] This article defines free software and provides some insight into the roots of FOSS. <br />
# [http://opensource.org/history History of the Open Source Initiative] - This article a brief overview of the start of the term "open source" and the OSI<br />
# [http://en.wikipedia.org/wiki/Open_source_software Wikipedia Open Source Software Article] This article talks about the history and development philosophy of FOSS. Read:<br />
## Sections 1-3 History, Definition, and Open Source Development Model<br />
## Section 5 Current Applications and Adoption<br />
# [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain Introduction to "The Cathedral and the Bazaar"] - This article describes the beginnings of FOSS (briefly) by someone who was there, especially for the establishment of "open source" and the OSI. <br />
## [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s11.html Social context of FOSS] - This section provides some motivation for why people start and contribute to FOSS projects.<br />
<br />
==== 3. Student Involvement in FOSS ====<br />
<br />
Student involvement in development of a large software project is an excellent way to motivate the need for software engineering skills, teamwork, and other aspects of professional software work. The use of FOSS projects as a setting for this type of student experience has potential and advantages that are difficult to match in a typical classroom setting.<br />
<br />
A discussion of student participation in HFOSS including data on aspects of student learning and references to prior publications in this area is available in a draft manuscript [[Media:HFOSS_Manuscript.docx | here]]. This manuscript is under review for publication so we ask that you not distribute it further or post it online.<br />
<br />
There is also some overview material on student involvement available in the [http://teachingopensource.org/index.php/Practical_OSS_Exploration Practical Open Source Exploration] text that was developed by the TeachingOpenSource community. The following readings will help explain the use of FOSS projects for learning as well as the feeling of being "productively lost". <br />
# [http://teachingopensource.org/index.php?title=Practical_OSS_Exploration_-_Foreword&direction=next&oldid=3605#Why_is_This_Book_Necessary.3F Motivation for using FOSS in courses]<br />
# [http://teachingopensource.org/index.php?title=Practical_OSS_Exploration_-_Foreword&direction=next&oldid=3605#Why_Traditional_Student_Projects_Are_Ineffective FOSS in Student Projects]<br />
<br />
==== 4. Humanitarian FOSS ==== <br />
<br />
To finish out our discussion, we should explain the use of Humanitarian FOSS in this workshop. '''Humanitarian FOSS (HFOSS)''' is FOSS that does some social good. HFOSS projects can range from disaster management, micro-finance, health care, education and more. We have chosen to focus on HFOSS as the altruistic nature of HFOSS has the potential to attract more computing majors, and women in particular. We have chosen to use HFOSS as our project space as these projects are particularly amenable to student participation. <br />
<br />
# Review the list of [http://www.foss2serve.org/index.php/HFOSS_Communities HFOSS projects] and identify one that captures your interest. You'll be working with this project for at least a couple of months so find one in which you are interested. You can see some of the people already working on the project as well as some of the activities. Note that most of the activity happens on the actual HFOSS site so don't be put off by a project with no activity on the foss2serve site. You can also change your selection in the future. <br />
<br />
=== Deliverables ===<br />
<br />
POSSE: None (but have a project in mind as directed above)<br />
<br />
Possible deliverables for use with students could be:<br />
* Paper summarizing what students learned about open source<br />
* Description of the difference in the philosophies of the Free Software Foundation and the Open Source Initiative<br />
* Brief description of open source project to which they would like to contribute including possible contributions and why they chose the project<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 />
'''Below are the questions that need to be answered to provide assessment for this activity along with a sample assessment table.'''<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 />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
Comments to instructor using this activity with students:<br />
* Section 3 may be omitted<br />
* Instructors may want to broaden the list of HFOSS projects that students look at. A broader list is [http://foss2serve.org/index.php/HFOSS_Projects here]<br />
<br />
=== Additional Information ===<br />
<br />
{| class="wikitable"<br />
|- <br />
| '''ACM Knowledge Area/Knowledge Unit''' || SP Intellectual Property [[ACM_Body_of_Knowledge]]<br />
|-<br />
| '''ACM Topic''' || Goals of Open Source (from https://www.acm.org/education/CS2013-final-report.pdf)<br />
|-<br />
| '''Level of Difficulty''' || Easy<br />
|-<br />
| '''Estimated Time to Completion''' || 60-90 minutes <br />
|-<br />
| '''Materials/Environment''' || Access to Internet/Web and web browser. <br />
|-<br />
| '''Author''' || Heidi Ellis<br />
|-<br />
| '''Source''' || None<br />
|-<br />
| '''License''' || Licensed CC BY-SA <br />
|}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Below are suggestions for an open source community member who is working in conjunction with the instructor.<br />
*<br />
<br />
<br />
--------------------<br />
{{License CC BY SA}}<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Introduction]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/MediaWiki:SidebarMediaWiki:Sidebar2017-02-04T14:46:28Z<p>Stoney.jackson: </p>
<hr />
<div>* Events<br />
** POSSE|POSSE<br />
** SIGCSE_2017_POSSE_Roundup|POSSE Roundup 2017<br />
** Funding_Support_for_Instructors|Funding Opportunities<br />
** Category:Workshops|Workshops<br />
* Learning Resources<br />
** Category:Learning Activity|Learning Activities<br />
** Category:Pathways|Pathways<br />
** Category:Courses|Courses<br />
** HFOSS_Links|HFOSS Links<br />
* HFOSS Projects<br />
** Category:Gnome MouseTrap|GNOME MouseTrap<br />
** Category:OpenMRS|OpenMRS<br />
** Category:Sahana|Sahana<br />
** Category:Ushahidi|Ushahidi<br />
** HFOSS_Projects|Other Projects<br />
* Evaluation<br />
** Evaluation Instruments|Instruments<br />
** Survey Data|Data<br />
** Publications|Publications<br />
* Navigation<br />
** mainpage|mainpage-description<br />
** helppage|help<br />
** Category:Contents|Categories<br />
** Special:AllPages|All Pages<br />
* SEARCH<br />
* TOOLBOX<br />
* LANGUAGES</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/TeamMeeting_2017_02_AgendaTeamMeeting 2017 02 Agenda2017-02-04T00:47:35Z<p>Stoney.jackson: /* Schedule Friday */</p>
<hr />
<div>==<center>Team Meeting Agenda</center>==<br />
<center>'''Nassau Community College<br/>February 3-4, 2017'''</center><br />
<br />
<br />
[https://docs.google.com/document/d/1rnlbiuugmSq4V3nNvK-p0ep6U3-XEA_49OVYvCjxUC4/edit#heading=h.q5uf2y84l47m Notes for this meeting]<br />
<br />
== Prep for the Meeting: ==<br />
* Add agenda items to [https://trello.com/c/7fiBE68k Trello card]<br />
<br />
== Schedule Overview ==<br />
* Thursday: arrive evening<br />
* Friday: <br />
** Target start time of 9 AM at NCC in CCB 254 - Lunch will be provided<br />
** Casual / Working dinner<br />
** Work until 8 or 9 Friday evening<br />
* Saturday<br />
** Breakfast on your own<br />
** Lunch will be provided<br />
** Goal of working until 3pm at least depending on when people need to travel to get home.<br />
<br />
== Goals for this Meeting ==<br />
* Advance the project work<br />
* Prepare for SIGCSE<br />
* Prepare for POSSE 2017-04<br />
<br />
Specific work items drawn from Trello card<br />
<br />
<br />
== Schedule Friday ==<br />
<br />
*9:00 - Team meeting<br />
*9:30 - Work planning for the day<br />
*10:00 - 12:00 - Time boxed sprints<br />
*12:00 - 1:00 - Lunch and walk<br />
*1:00 - 3:00 - Time boxed sprints<br />
*3:00 - 3:30 - Break<br />
*3:30 - 6:00 - Time boxed sprints<br />
*6:00 - 7:00 - Dinner (delivered)<br />
*7:00 - 8:00 - Sprint<br />
*8:00 - 8:30 - Planning for Saturday<br />
<br />
<br />
== Schedule Saturday ==<br />
<br />
*9:00 - Team meeting<br />
*9:30 - Work planning for the day<br />
*10:00 - 12:00 - Time boxed sprints<br />
*12:00 - 1:00 - Lunch and walk<br />
*1:00 - 3:00 - Time boxed sprints<br />
<br />
[[Category: TeamMeeting ]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/TeamMeeting_2017_02_AgendaTeamMeeting 2017 02 Agenda2017-02-04T00:47:02Z<p>Stoney.jackson: /* Schedule */</p>
<hr />
<div>==<center>Team Meeting Agenda</center>==<br />
<center>'''Nassau Community College<br/>February 3-4, 2017'''</center><br />
<br />
<br />
[https://docs.google.com/document/d/1rnlbiuugmSq4V3nNvK-p0ep6U3-XEA_49OVYvCjxUC4/edit#heading=h.q5uf2y84l47m Notes for this meeting]<br />
<br />
== Prep for the Meeting: ==<br />
* Add agenda items to [https://trello.com/c/7fiBE68k Trello card]<br />
<br />
== Schedule Overview ==<br />
* Thursday: arrive evening<br />
* Friday: <br />
** Target start time of 9 AM at NCC in CCB 254 - Lunch will be provided<br />
** Casual / Working dinner<br />
** Work until 8 or 9 Friday evening<br />
* Saturday<br />
** Breakfast on your own<br />
** Lunch will be provided<br />
** Goal of working until 3pm at least depending on when people need to travel to get home.<br />
<br />
== Goals for this Meeting ==<br />
* Advance the project work<br />
* Prepare for SIGCSE<br />
* Prepare for POSSE 2017-04<br />
<br />
Specific work items drawn from Trello card<br />
<br />
<br />
== Schedule Friday ==<br />
<br />
*9:00 - Team meeting<br />
*9:30 - Work planning for the day<br />
*10:00 - 12:00 - Time boxed sprints<br />
*12:00 - 1:00 - Lunch and walk<br />
*1:00 - 3:00 - Time boxed sprints<br />
*3:00 - 3:30 - Break<br />
*3:30 - 6:00 - Time boxed sprints<br />
*6:00 - 7:00 - Dinner (delivered)<br />
*7:00 - 8:00 - Sprint<br />
*8:00 - 8:30 - Planning for Saturday<br />
<br />
<br />
[[Category: TeamMeeting ]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Pathway_Format_with_DirectionsPathway Format with Directions2017-01-07T02:12:29Z<p>Stoney.jackson: Initial draft</p>
<hr />
<div>__NOTOC__<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''Title'''<br />
| ...<br />
|-<br />
| '''Contribution'''<br />
| ...<br />
|-<br />
|}<br />
<br />
= Pre-requisites =<br />
Contributor must be able to accomplish the following tasks in the following areas:<br />
<br />
= Steps =<br />
Follow the project’s policies and practices to complete the steps below.<br />
{| class="wikitable"<br />
|-<br />
! Step<br />
! Step outcome<br />
! Process skill focus<br />
! Related Learning Activity<br />
|-<br />
|-<br />
| 1. Description of first step<br />
| Outcome of this step<br />
| Process skills useful for completing this step<br />
| Links to learning activities that support this step<br />
|-<br />
| 2. ...<br />
| ...<br />
| ...<br />
| ...<br />
|}<br />
<br />
= Notes for Learning Activities Related to this Pathway =<br />
When creating activities ... <br />
<br />
[[Category: Pathway]]</div>Stoney.jacksonhttp://www.foss2serve.org/index.php/Bug_SelectionBug Selection2017-01-06T14:57:01Z<p>Stoney.jackson: Supports Pathway - Verify a Bug</p>
<hr />
<div>__NOTOC__<br />
{| border="1"<br />
|- <br />
|'''Title''' || Bug Selection<br />
|-<br />
|'''Overview''' || One way to make a contribution to an open source project is to select a bug, fix the bug, and submit the solution back to the community. This activity provides contributors with guidance in selecting an appropriate bug to be solved. <br />
|- <br />
|'''Prerequisite Knowledge''' || Students should be familiar with how bug trackers work -- see [[http://foss2serve.org/index.php/Bug_Tracker_Activity| Bug Tracker Activity]]. <br />
|-<br />
|'''Learning Objectives''' || Student will be able to review a list of bugs and identify five relevant bugs that they have the skills to solve. <br />
|}<br />
<br />
=== Background: ===<br />
<br />
<br />
=== Directions: ===<br />
# In order to identify an appropriate bug to be solved, you must first identify the criteria you should use to select an appropriate bug. Spend some time thinking about the following questions before you start searching the bug tracker: <br />
#* What platform is the application run on?<br />
#* What parts of the application are you familiar with? <br />
#* What programming language is used?<br />
#* What database is used?<br />
#* What other technologies are used?<br />
#* How complex is the code base? <br />
#* Where is the documentation?<br />
#* What kinds of things are you able to contribute?<br />
#** Test cases?<br />
#** Design?<br />
#** Documentation?<br />
#** Code?<br />
#** Installation instructions?<br />
# Once you have some understanding of the types bugs that you are comfortable addressing, find the bug tracker for the project. <br />
# Peruse the bug tracker and identify a set of five possible bugs. You may need to ask the community to ensure that the bugs are still relevant.<br />
<br />
=== Deliverables: ===<br />
A list of bugs including bug number, brief description (in your own words, not copied from the bug report), and a feasibility assessment of how likely you will be able to solve the bug. The feasibility should include an explanation of why you think that you have the skills to solve the bug. The list should be organized in order from easiest to solve to most difficult. One possible format for the deliverable might be:<br />
<br />
{| border="1"<br />
|- <br />
|'''Bug Number''' ||'''Short Description'''||'''Bug Status'''||'''URL for Bug'''||'''Analysis'''<br />
|-<br />
|}<br />
<br />
'''Alternative submission''' Could also ask for estimate of resources, time, and/or lines of code needed to solve the bug and/or set of test cases to test solution. <br />
<br />
=== Comments: ===<br />
If you're working with a specific open source project:<br />
* ask the project (via IRC or mailing list) if there are a particular set of bugs that your students should focus on. Providing a subset of bugs for students to investigate will reduce time students spend searching for bugs. <br />
<br />
=== Additional Information: ===<br />
{| border="1"<br />
|- <br />
|'''Knowledge Area/Knowledge Unit''' || Software Development Fundamentals//Software Verification and Validation<br />
|-<br />
|'''Topic''' || Defect tracking<br />
|-<br />
|'''Level of Difficulty''' || Medium (requires some understanding of the intended functionality of the software, ability to use bug tracking software, and critical thinking skills) <br />
|-<br />
|'''Estimated Time to Completion''' || 60-90 minutes<br />
|-<br />
|'''Materials/Environment''' || Student needs access to the project's bug tracker, internet access. <br />
|-<br />
|'''Author''' || Heidi Ellis, based on Gina Likins <br />
|-<br />
|'''Source''' || [http://foss2serve.org/index.php/Bug_Gardening Bug Gardening Activity] <br />
|-<br />
|'''License''' || This work is licensed under a [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]<br />
|}<br />
<br />
=== Suggestions for the Open Source Project: ===<br />
<br />
Your community should have specific expectations around [support] that are published [somewhere]. For example, if your code will only work on Fedora versions newer than 19, then specify that. <br />
<br />
If there are a set of bugs that it would be more helpful to have someone verify, then marking those in some way would help the instructor.<br />
<br />
--------------------<br />
This work is licensed under a <br />
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]<br />
<br />
[[File:CC_license.png]]<br />
<br />
[[Category: Learning_Activity]]<br />
[[Category: Quality_and_Testing]]<br />
[[Category:Pathway_-_Verify_a_Bug]]</div>Stoney.jackson