User:Jtaormina
m |
m |
||
(One intermediate revision by one user not shown) | |||
Line 65: | Line 65: | ||
Possible activities that students can complete as part of a course incorporating FOSS: | Possible activities that students can complete as part of a course incorporating FOSS: | ||
1. Reading assignments (the Cathedral and the Bazaar) | 1. Reading assignments (the Cathedral and the Bazaar) | ||
+ | |||
2. Taking field trips (browsing a forge, assessing a project, creating a test set using Open MRS - all from http://www.xcitegroup.org/) | 2. Taking field trips (browsing a forge, assessing a project, creating a test set using Open MRS - all from http://www.xcitegroup.org/) | ||
+ | |||
3. Setting up a blog | 3. Setting up a blog | ||
+ | |||
4. Attend an IRC meeting | 4. Attend an IRC meeting | ||
+ | |||
5. Bugs | 5. Bugs | ||
a. re-creating known bugs and improving on the bug documentation by giving more detailed steps and information | a. re-creating known bugs and improving on the bug documentation by giving more detailed steps and information | ||
Line 76: | Line 80: | ||
b. running code and silencing compiler warnings, also fixing deprecation warnings | b. running code and silencing compiler warnings, also fixing deprecation warnings | ||
7. Documentation - read and identify deficiencies and make improvements | 7. Documentation - read and identify deficiencies and make improvements | ||
+ | |||
8. Blogging, continued | 8. Blogging, continued | ||
a. continuously add to a personal blog to provide a record of student work | a. continuously add to a personal blog to provide a record of student work | ||
b. document all student experiences within a FOSS project, including all problems encountered and solutions used to fix them | b. document all student experiences within a FOSS project, including all problems encountered and solutions used to fix them | ||
+ | |||
+ | |||
+ | [[Category:POSSE 2013-06]] |
Latest revision as of 10:08, 7 February 2017
JoAnne Taormina is an instructor of Computer Science and Mathematics at Nassau Community College. She is preparing to teach an independent study Computer Science course next fall which will be based on student participation in a Humanitarian Open Source Software project.
Before entering the teaching profession, JoAnne worked as a software engineer in various industries, including aerospace and mobile communications.
IRC conversation activity:
1. How do people interact?
People interact on IRC through by typing short, casual, messages to each other.
2. What is the pattern of communication?
A moderator starts the conversation. Others join in as appropriate. Periodically, the moderator will highlight a specific point by typing #info [text] as well as indicating a new task by typing #action [text].
3. Are there any terms that seem to have special meaning?
#action #agreed #help #info #idea #link #topic
4. Can you make any other observations?
No. I'm interested in seeing how my first IRC session will turn out.
Project Anatomy Activity
Sugar Labs Project
Activity Team / Contacts: Coordinators, Contributors (including a link to the TODO list where anyone can put his or her name next to a task to make a contribution), Sugar Mail List, IRC Channel
Development Team / Contacts: Coordinator (none), IRC Channel, People (no link to a TODO list)
Documentation Team/Contacts Coordinator (open), Mailing list, IRC Channel, Editors (no link to a TODO list)
Commonalities: All the teams have a section for the coordinators and contributors. The Activity Team also has a link to an extensive TODO list. The Activity and Documentation teams have mailing lists. All three teams reference the IRC channel where meetings take place.
Bugs
Types/Categories: Immediate Priority, Urgent Priority, New Blocker Bugs, and New Easy to Fix Tickets, Blocker, Critical, Major Information: Ticket number, component, summary, status, owner, type, severity
The project uses a web-based common repository.
A release cycle includes the following types of releases: development, beta, release candidate, and final release. A release roadmap is a plan for activities during one release cycle. Each new release cycle includes an updated release roadmap. The roadmap includes information for release dates and freeze points, list of modules and external dependencies, references to all tickets considered for the release, and references to new feature proposals.
Sahana Eden Project
Developers: Offers a step by step process for people interested in developing code for the project. (sign up for the mailing list, install the developer environment, read the guidebook - specifically chapters on customization and building a new module, check out the lists of code tasks to work on, join the IRC chat, read developer guidelines).
Testers: Provides a link to google spreadsheets for manual testing and Selenium for automated testing. Provides notes to testers regarding duplication of bug tickets (seems there is some process problem here). Also give bug reporting guidelines including a step by step "how to report a bug."
Designers: Offers a list of visual related tasks for graphic designers. Task are broken down into categories easy, intermediate, and advanced (no advanced tasks are listed at the moment).
Bug tracker: The initial page presents categories of bugs, but no actual bugs like Sugar Labs. The Active Tickets link shows that the categories for bugs are: defect/bug, enhancement, documentation, task. Associated with each ticket are: Ticket Summary Component Version Priority Type Owner Status Created
Repository: I think it's a local, not web-based repository.
The Sahana roadmap includes three different milestones: 0.9.0 Medway 88% complete; 1.0 Avon 66% complete, Milestone 2.0 (noname) 75% complete.
Possible activities that students can complete as part of a course incorporating FOSS: 1. Reading assignments (the Cathedral and the Bazaar)
2. Taking field trips (browsing a forge, assessing a project, creating a test set using Open MRS - all from http://www.xcitegroup.org/)
3. Setting up a blog
4. Attend an IRC meeting
5. Bugs
a. re-creating known bugs and improving on the bug documentation by giving more detailed steps and information b. closing fixed bugs - testing the bug with the current release and validating it is fixed c. adding tests
6. Code
a. reading code thoroughly - writing comments where they would be helpful b. running code and silencing compiler warnings, also fixing deprecation warnings
7. Documentation - read and identify deficiencies and make improvements
8. Blogging, continued
a. continuously add to a personal blog to provide a record of student work b. document all student experiences within a FOSS project, including all problems encountered and solutions used to fix them