View source

You do not have permission to edit this page, for the following reason:

You can view and copy the source of this page:

Becka Morgan is an Assistant Professor of Computer Science at Western Oregon University. Becka returned to school in 2005 to complete a Bachelor degree, originally planned to be in Political Science. After taking a CS class she fell in love with computer science and changed her major. In 2008 Becka earned her BS in Computer Science, emphasis in Software Engineering, graduating summa cum laude. During the last year of her undergrad Becka was offered a job teaching computer science at WOU. She earned a MS in Management and Information Systems in 2009 and her PhD in Computer Science Education in December of 2012. Her dissertation is titled How does a Collaborative Community Affect Diverse Students' Engagement with an Open Source Software Project: A Pedagogical Paradigm. The Open Source class developed as a research model for Dr. Morgan (yes, it is still fun to write the Dr. part :-) ) has been adopted by the CS department for both the undergrad as well as the Masters program, however she feels that there is a much better way to teach people how to participate in OSS and so she is very excited about Posse. In her spare time Becka is busy with her two teenage daughters, volunteer work with Habitat for Humanity, and riding her bike. == IRC Activity == *How do people interact? The interaction between participants was familiar, as if it was part of an ongoing conversation. It appears as though this meeting is between a group who has worked together for awhile. *What is the pattern of communication? Most of the conversation is direct, between a few people, however there are places where there is more then one conversation. This requires the ability to follow multiple threads at once. *Are there any terms that seem to have special meaning? There are emoticons used to relay expressions. This example also uses the construct of ''nick'': to show specifically addressing someone. *Can you make any other observations? There are #''command'' that are used by the meeting bot to organize the meeting notes, highlighting important information so it stands out in the notes. ==Guided Tour== ===''The Sugar Labs Project''=== ====Community==== * Activity Team The Activities Contact page has a greater number of contributors and leaders/coordinators. They allow people to join by providing an invitation to add yourself to the list and a link to pick something from the TODO list. They also have "Welcome to the team!". The most inviting and welcoming list. * Development Team Short list of members. No leader/coordinator. Not very welcoming. * Documentation Team Only two people listed as contacts. It is not clear if this is the whole team or if they are the only two people to contact. Also no leader/coordinator. A bit more welcoming feel (information shared about the two editors) then Dev Team, but not as welcoming as Activity Team. * Commonalities All of the teams have an infrastructure for communication using an IRC channel, however they all appear to hang out in the same channel. The activities team provides a link to the newbies channel, usually a more comfortable place for newcomers to ask questions. ====Tracker==== Tickets are divided into categories based on urgency of the bug. There is also a section of easy bug fixes which is a great place for newbies to start. For each ticket you can see the ticket number, which component is effected, the summary of what the bug does, the status (assigned, reopened), who owns it, its type (whether it is an actually a bug or a feature request) and severity. These seem to be the triaged bugs (?). The new bugs and sugar-love bugs have an assigned ticket number, the component effected, summary of the problem, type of bug (whether it is an actually a bug or a feature request), severity of the bug (critical, blocker(?), major) and its priority (immediate, urgent, high, normal, low, unspecified). This system provides multiple ways to query the bugs which is useful. I did note that there seem to be a great number of bugs that have been on the list for a long time. ====Repository==== This project is using a web-based repository in gitHub. ====Release Cycle==== The release cycle page describes how a release happens and each phase of the release. The roadmap shows what has happened thus far (what is frozen) and projects the dates of further freezes. This schedule provides deadline information. ===''The Sahana Eden Project''=== ====Community==== * Developers Provides straight forward, easy to follow steps to get up and running as a developer. Mailing list and IRC information given for discussion. * Testers Little information on testing. This appears to be a page where the developers express their expectations of testers. Mailing list link given for discussion. * Designers Little overall information. No information on communication options. * Commonalities The pages all provide some indication of how to participate, but the developer page is by far the most beginner friendly. * Comparison Sugar and Sahana The contact pages in Sugar Labs that are reflected above are completely different than the participation pages reflected for Sahana. However each of the three categories in Sugar Labs have pages for getting involved that do a very good job of providing good step by step instructions. All of the categories in Sugar Labs appear to have extensive documentation the is divided into bite size pieces so you can find things easily. ====Tracker==== * How is the information here different than the information found on the Sugar Labs tracker page? The number of options to pull up tickets seems a bit overwhelming in Sahana. The Sugar Labs bug tracker seemed more intuitive to me. The Sahana tracker, however, does display the age of a bug which I think is important. Once I got to the actual bug reporting pages they show the same information - ticket number, which component is effected, the summary of what the bug does, the status (Sugar Labs - assigned, reopened. Sahana - accepted, assigned, new), who owns it, its type (Both - whether it is an actually a bug or a feature request) and severity (more broken down in Sugar Labs). Both bug tracking systems also have the ability to sort by each of the headings and are color coded by severity. * Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket. Ticket number, Summary of the bug, Component effected, Version, Priority (critical, major, minor, trivial), Type (defect/bug, documentation, enhancement), Owner, Status (accepted, assigned, new), the date Created. ====Repository==== Sahana is hosted on gitHub which is an online repository. ====Release Cycle==== There is a list of milestones but there are no dates associated with them except the first one (which is 17 months late). it is unclear when the releases are suppose to happen so it would be difficult for developers to have a sense of urgency to find a stopping point in their work to allow a release. ==FOSS in Courses Planning 1== The following is the beginning of a course outline. {| class="wikitable" border="2" |+ Outline FOSS course |- ! Week !! Assignment/Activity !! Homework |- | 1 Intro || Intro to Class || [http://firstmonday.org/ojs/index.php/fm/article/view/578/499 The Cathedral and the Bazaar] |- | || Intro to Wikis ** (Provide a wiki to play with) || [http://www.xcitegroup.org/softhum/doku.php?id=f:assignment_freevsopen Free vs. Open] |- | || Intro to IRC ** (create an IRC channel and have students "talk") |- | 2 || Blog activity/Introduce OSS projects like Ubuntu, Firefox, Moodle, etc. (Projects the students are familiar with) || [http://blog.smartbear.com/software-quality/bid/167051/ 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star] |- | || "Anatomy Activity ** Evaluate projects based on criteria (Similar to Sahana vs SugarLabs) This will help students focus on things to look for when finding a project" || [http://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/ How to Contribute to Open Source Without Coding] |- | || Begin exploration of areas of interest/Codes of Conduct || BLOG (Ongoing Blog about experiences) |- | 3 Teams and communication || FOSS field trip ** Ohloh - find projects of interest |- | || Form teams based on interests/Set up team IRC channels and wikis/Determine group meeting schedule outside of class (via IRC, logs to be turned in) || Each group member find a minimum of 2 projects that meet group requirements. Share them in weekly IRC. |- | || Determine group OSS project || BLOG |} == Project Evaluation == [[File:FOSS_Evaluation_Ushahidi.xlsx|200px|thumb|left|Evaluation of Ushahidi Project]] [[Category:POSSE 2013-06]]

Return to User:Bmorgan.