User:Josh.dehlinger
From Foss2Serve
(Difference between revisions)
(→Josh Dehlinger) |
|||
| (12 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==== Josh Dehlinger ==== | ==== Josh Dehlinger ==== | ||
| − | Josh Dehlinger is an Associate Professor in the [http://www.towson.edu/cosc/ Department of Computer and Information Sciences] at [http://www.towson.edu Towson University]. Before joining Towson University in 2008, he was a Research Associate in the [http://www.ece.virginia.edu/ Charles L. Brown Department of Electrical and Computer Engineering] at [http://www.virginia.edu/ The University of Virginia]. He received his Ph.D. in Computer Science from [http://http://www.iastate.edu/ Iowa State University] in 2007 working under the advisement of [http://web.cs.iastate.edu/~rlutz/ Dr. Robyn Lutz]. | + | Josh Dehlinger is an Associate Professor and Director of the Undergraduate Program in Computer Science in the [http://www.towson.edu/cosc/ Department of Computer and Information Sciences] at [http://www.towson.edu Towson University]. Before joining Towson University in 2008, he was a Research Associate in the [http://www.ece.virginia.edu/ Charles L. Brown Department of Electrical and Computer Engineering] at [http://www.virginia.edu/ The University of Virginia]. He received his Ph.D. in Computer Science from [http://http://www.iastate.edu/ Iowa State University] in 2007 working under the advisement of [http://web.cs.iastate.edu/~rlutz/ Dr. Robyn Lutz]. |
| − | '''Part A, Activity 4: [http://foss2serve.org/index.php/Intro_IRC_Activity Introduction to IRC]''' | + | ---- |
| + | |||
| + | |||
| + | '''Part A, Part 1, Activity 4: [http://foss2serve.org/index.php/Intro_IRC_Activity Introduction to IRC] - Walk through of IRC Conversation''' | ||
* ''How do people interact?'' Interaction is quite informal, conversational and concise. | * ''How do people interact?'' Interaction is quite informal, conversational and concise. | ||
| Line 13: | Line 16: | ||
* ''Can you make any other observations?'' None. | * ''Can you make any other observations?'' None. | ||
| + | |||
| + | '''Part A, Part 3, Activity 3: [http://foss2serve.org/index.php/Intro_IRC_Activity Introduction to IRC] - Join and Observe Channel Discussion''' | ||
| + | |||
| + | * ''Summarize your observations of a selected HFOSS project(s).'' Between 7/18/15 - 7/20/15, I observed the #foss2serve, #openmrs and #ushahidi IRC channels using the [https://kiwiirc.com Kiwi IRC] web application. During this period, there was very little / no activity on both the #foss2serve and #openmrs channels, but the #openmrs channel was somewhat active with most of the messages seeming to be automated bot messages from a build/repository/issue tracker agent indicating pull requests were made, commits were made or files changed. | ||
| + | |||
| + | '''Part A, Part 6, Activity 4: [http://foss2serve.org/index.php/Project_Anatomy_Activity Anatomy of a FOSS Project] - Guided Tour: Sugar Labs Project''' | ||
| + | |||
| + | * '' Community''. The Activity Team develops and maintains many of the activities available for Sugar and recruits, mentors and supports folks who develop Sugar activities. The Development Team implements, builds and maintains the core Sugar environment and works with the [http://wiki.sugarlabs.org/go/Design_Team Design Team]. Finally, the Documentation Team provides the Sugar community with high quality documentation, including learners' manuals, programming references, and tutorials. All of the teams have clearly defined mission statements and distinct roles within the Sugar Project and collaborate/coordinate with other teams. Both the Activity and Development team utilize IRC for meetings (its not immediately clear what the Documentation Team uses). | ||
| + | |||
| + | * ''Tracker''. The Sugar Project uses an installation of [http://http://trac.edgewall.org/ Trac] as their bug tracker and utilizes defect/enhancement/task ticket types/categories. Within each ticket, the information includes: Reported By, Priority, Component, Severity, Bug Status, Owned By, Milestone, Version and Description. Each ticket also includes a change history with comments and/or screenshots. | ||
| + | |||
| + | * ''Repository''. The Sugar Project uses a [https://git-scm.com/ GIT]-based repository that seems to be local to Sugar Labs and not utilizing a common web-based repository site, such as [http://sourceforge.net/ Sourceforge]. | ||
| + | |||
| + | * ''Release Cycle''. It appears that the Sugar Project develops a short-term roadmap at the beginning of each development cycle outlining the features to be included in the current release cycle. | ||
| + | |||
| + | '''Part A, Part 6, Activity 4: [http://foss2serve.org/index.php/Project_Anatomy_Activity Anatomy of a FOSS Project] - Guided Tour: The Sahana Eden Project''' | ||
| + | |||
| + | * '' Community''. The Developers, Testers and Designers for The Sahana Eden Project all seem to conform to their role (i.e., the developers are mainly responsible for development). However, unlike the [http://sugarlabs.org/ Sugar Project], the team descriptions are less clear as there are no clear mission statements for the teams, it is not apparent how to join a team nor are there explicit meeting venues (e.g., IRC). | ||
| + | |||
| + | * ''Tracker''. Like the The Sugar Project, The Sahana Eden Project seems to use an installation of [http://http://trac.edgewall.org/ Trac] as their bug tracker and utilizes defect/enhancement/task ticket types/categories. I also noticed that they include a documentation type/category. Within each ticket, the information includes: Reported By, Priority, Component, Severity, Bug Status, Owned By, Milestone, Version and Description and each ticket also includes a change history with comments and/or screenshots as seen in the previous project. This is expected since they seem to be utilizing the same tracker software. The only immediate difference is that the tracker in The Sahana Eden Project first presents the user with a menu to view tickets organized by various statuses (e.g., milestone, version, etc.). | ||
| + | |||
| + | * ''Repository''. The Sahana Eden Project seems to use a web-based [https://git-scm.com/ GIT] repository hosted at [https://github.com/ GitHub]. | ||
| + | |||
| + | * ''Release Cycle''. The Sahana Eden Project has a long-term roadmap that provides a listing of features to be included in several minor and major future versions of the software. | ||
| + | |||
| + | '''Part B, Part 4, Activity 4: [http://foss2serve.org/index.php/FOSS_In_Courses_Activity FOSS in Courses Activity]''' | ||
| + | |||
| + | * I have utilized FOSS projects in the software testing / software quality assurance classes that I teach for the last 3 years. However, in most semesters, I allow the student groups to browse/select an FOSS from SourceForge with the goal of improving the FOSS project’s software quality through the contribution of tests, refactorings, documentation, bug fixes, etc. In general, I don’t require students to actually contribute back to the FOSS community; rather, I encourage the better groups to contribute there work (although, I believe very few actually follow through). The main reason for this was because, often times, the projects that the student groups selected were small, inactive and trivial games. My goal for the project(s) was more focused on exposure to FOSS projects and working with others’ code rather than being involved in the FOSS community. | ||
| + | |||
| + | * After looking at the existing assignment/project ideas, in particular the [http://teachingopensource.org/index.php/RIT/The_Course RIT class], I feel more confident in requiring my students to contribute back to active FOSS projects, such as the OpenMRS FOSS project. I can see that using some of the assignments/materials from the RIT course would be appropriate for these classes. | ||
| + | |||
| + | Since the original POSSE I attended, I have worked on and off with Ushahidi; in particular, we set up our own instance of Ushahidi and developed Android and iOS mobile applications to report and map an invasive plant species and utilized Ushahidi as the web application to map/visualize its spread. | ||
| + | |||
| + | |||
| + | [[Category:POSSE 2015-09]] | ||
Latest revision as of 12:54, 16 October 2017
Josh Dehlinger
Josh Dehlinger is an Associate Professor and Director of the Undergraduate Program in Computer Science in the Department of Computer and Information Sciences at Towson University. Before joining Towson University in 2008, he was a Research Associate in the Charles L. Brown Department of Electrical and Computer Engineering at The University of Virginia. He received his Ph.D. in Computer Science from Iowa State University in 2007 working under the advisement of Dr. Robyn Lutz.
Part A, Part 1, Activity 4: Introduction to IRC - Walk through of IRC Conversation
- How do people interact? Interaction is quite informal, conversational and concise.
- What is the pattern of communication? The pattern of communication follows a typical stand-up meeting in Scrum where each developer talks about: 1. What did I accomplish; 2. What obstacles are impeding my progress; and, 3. What will I work on next. Clearly, in this meeting Darci is the coordinator/project manager since she is leading the meeting and keeping it focused.
- Are there any terms that seem to have special meaning? There are several IRC meetbot specific terms that have special meeting, including #topic, #info, #action and #link. There are also some notation to indicate non-verbal types of communication, including name: to direct a comment to a person (i.e., equivalent to the Twitter version of @name).
- Can you make any other observations? None.
Part A, Part 3, Activity 3: Introduction to IRC - Join and Observe Channel Discussion
- Summarize your observations of a selected HFOSS project(s). Between 7/18/15 - 7/20/15, I observed the #foss2serve, #openmrs and #ushahidi IRC channels using the Kiwi IRC web application. During this period, there was very little / no activity on both the #foss2serve and #openmrs channels, but the #openmrs channel was somewhat active with most of the messages seeming to be automated bot messages from a build/repository/issue tracker agent indicating pull requests were made, commits were made or files changed.
Part A, Part 6, Activity 4: Anatomy of a FOSS Project - Guided Tour: Sugar Labs Project
- Community. The Activity Team develops and maintains many of the activities available for Sugar and recruits, mentors and supports folks who develop Sugar activities. The Development Team implements, builds and maintains the core Sugar environment and works with the Design Team. Finally, the Documentation Team provides the Sugar community with high quality documentation, including learners' manuals, programming references, and tutorials. All of the teams have clearly defined mission statements and distinct roles within the Sugar Project and collaborate/coordinate with other teams. Both the Activity and Development team utilize IRC for meetings (its not immediately clear what the Documentation Team uses).
- Tracker. The Sugar Project uses an installation of Trac as their bug tracker and utilizes defect/enhancement/task ticket types/categories. Within each ticket, the information includes: Reported By, Priority, Component, Severity, Bug Status, Owned By, Milestone, Version and Description. Each ticket also includes a change history with comments and/or screenshots.
- Repository. The Sugar Project uses a GIT-based repository that seems to be local to Sugar Labs and not utilizing a common web-based repository site, such as Sourceforge.
- Release Cycle. It appears that the Sugar Project develops a short-term roadmap at the beginning of each development cycle outlining the features to be included in the current release cycle.
Part A, Part 6, Activity 4: Anatomy of a FOSS Project - Guided Tour: The Sahana Eden Project
- Community. The Developers, Testers and Designers for The Sahana Eden Project all seem to conform to their role (i.e., the developers are mainly responsible for development). However, unlike the Sugar Project, the team descriptions are less clear as there are no clear mission statements for the teams, it is not apparent how to join a team nor are there explicit meeting venues (e.g., IRC).
- Tracker. Like the The Sugar Project, The Sahana Eden Project seems to use an installation of Trac as their bug tracker and utilizes defect/enhancement/task ticket types/categories. I also noticed that they include a documentation type/category. Within each ticket, the information includes: Reported By, Priority, Component, Severity, Bug Status, Owned By, Milestone, Version and Description and each ticket also includes a change history with comments and/or screenshots as seen in the previous project. This is expected since they seem to be utilizing the same tracker software. The only immediate difference is that the tracker in The Sahana Eden Project first presents the user with a menu to view tickets organized by various statuses (e.g., milestone, version, etc.).
- Release Cycle. The Sahana Eden Project has a long-term roadmap that provides a listing of features to be included in several minor and major future versions of the software.
Part B, Part 4, Activity 4: FOSS in Courses Activity
- I have utilized FOSS projects in the software testing / software quality assurance classes that I teach for the last 3 years. However, in most semesters, I allow the student groups to browse/select an FOSS from SourceForge with the goal of improving the FOSS project’s software quality through the contribution of tests, refactorings, documentation, bug fixes, etc. In general, I don’t require students to actually contribute back to the FOSS community; rather, I encourage the better groups to contribute there work (although, I believe very few actually follow through). The main reason for this was because, often times, the projects that the student groups selected were small, inactive and trivial games. My goal for the project(s) was more focused on exposure to FOSS projects and working with others’ code rather than being involved in the FOSS community.
- After looking at the existing assignment/project ideas, in particular the RIT class, I feel more confident in requiring my students to contribute back to active FOSS projects, such as the OpenMRS FOSS project. I can see that using some of the assignments/materials from the RIT course would be appropriate for these classes.
Since the original POSSE I attended, I have worked on and off with Ushahidi; in particular, we set up our own instance of Ushahidi and developed Android and iOS mobile applications to report and map an invasive plant species and utilized Ushahidi as the web application to map/visualize its spread.
