User:Tom.naps

Revision as of 14:50, 30 July 2015

Tom Naps

For over 20 years Tom Naps was the primary Computer Science instructor at a small liberal arts college (Lawrence University in Appleton WI) where the Computer Science concentration was integrated into a Mathematics major. Currently he is completing his 14th year in a seven-member Computer Science Department at the University of Wisconsin Oshkosh.

Tom is an active contributor to two large open-source projects in algorithm visualization. The first of these, JHAVE, delivers instructional visualizations on algorithms that span the entire curriculum. It relies on a client-server architecture, with both the client and server written in Java. Since 2011 he has been actively involved in the OpenDSA (Open Data Structures and Algorithms) project hosted at Virginia Tech. The client software for OpenDSA is developed in JavaScript, and that is where Tom has focused his efforts. The server back-end is currently written in Python using the Django framework.

At UWOshkosh, Tom has taught most of the courses in the curriculum. In particular he often teaches a project-oriented Software Engineering II course, and it is in that course that he hopes to incorporate HFOSS.

Intro IRC Activity, Answers to Part 1 questions

• How do people interact? Conversationally, using short phrases with the emphasis on communicating the essential meaning of what they intend to say instead of on the grammatical correctness

• What is the pattern of communication? At least in the sample meeting, I would characterize the pattern as an initial session in which the participants reported on progress made and problems encountered since the last meeting. Each reported item was followed by a brief discussion. This initial session was followed by a wrap-up session in which goals were established to hopefully be reached before the next meeting.

• Are there any terms that seem to have special meaning? The meetbot tags (indicated by # and the green font) help to organize the way one reads the transcript of the meeting. In a sense they breakdown the meeting into a hierarchical structure -- with #topics broken down into #info and #action items.

• Can you make any other observations? I would think that the transcript of the meeting is most useful if one of the participants uses it to write up a set of minutes for the meeting as soon as possible after the meeting concludes. That set of minutes then becomes the official record of the meeting, providing a much more readable form than the transcript itself.

Intro to IRC Activity Part 3 – Join and Observe Channel Discussion

I joined and observed the discussion at the #OpenMRS IRC chat. Perhaps not unexpectedly, this was much more freeform than the organized meeting, the logs of which we read and wrote about in the answers to the Part 1 questions. There was no organization of topics using the #topic tag that we had seen in the logs of the session from Part 1. Instead many of the posts to the OpenMRS chat were just (apparently automated) notices from "OpenMRSBot" that a member of the project had posted an issue/update at the project's repository. So in that sense, listening in on the #OpenMRS channel would help to keep me posted on the most recent activity at the repository. Other entries at the #OpenMRS IRC chat seemed to be questions from various participants of the form "How do I ...?" There were many more questions posed than answers given, although in some cases respondents to the question would provide a link the questioner could chase down to at least find resources that might help.

Project Anatomy Activity - Sugar Labs

• Community - Follow the 'Contacts' link (found in the green option bar) for each of the following teams and summarize the information you find there. For example, are there any commonalities? Is there something distinct for each type of team?

1. Activity Team - This team is responsible for developing the learning activities for students (that is, the things that students do to foster learning) that consequently run on the Sugar platform
2. Development Team - This team builds the software for the infrastructure on which the activities (see previous team) run
3. Documentation Team - This team is responsible for developing all the documentation for the Sugar project. This includes documentation for both using and developing activities as well as the API documentation for the infrastructure platform. Hence various members of the documentation team must understand what the Activity team and Development team do without necessarily being aware of the lower level details of how it is done.

In very broad terms, the Development team focuses on coding, the Activity team focuses on authoring educational materials that use the platform, and the Documentation team must provide manuals that help new contributors plug their efforts into the other teams.

• Tracker - Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Each ticket includes a Summary, the Status of the ticket (new, assigned, re-opened), the Owner of the ticket, the Type (defect or enhancement), the Priority (urgent, high, normal, and a Milestone (most of which show as "Unspecified")

• Repository -- http://git.sugarlabs.org/sugar-base Can you determine from the information provided here whether the project uses a web-based common repository or a local repo?

There's an indication at the bottom of the repository page that it is powered by "Gitorius" at gitorius.org. However, following the link to http://gitorius.org merely leads to a page indicating that all gitorius repositories are being migrated to http://archive.org. That Sugar is using git (a distributed version control system) is an indication that each user maintains a local copy of the repository with changes ideally ultimately pushed to the master repository which would live at archive.org (wherever that is). However, that status of the master repository seems somewhat dubious, since the phrasing at gitorius.org indicated only that "The repositories (being migrated) will soon be available for read-only access". The last push to this master repository seemed to take place in March 2014. Right now it seems to be a bit unclear how one would acquire the Sugar base to work from.

• Release cycle -- Information about Sugar's release cycle and roadmap can be found here. Include an entry on your wiki page that describes how the release cycle and roadmap update are related.

Each release cycle apparently includes four sub-releases -- the development, beta, release candidate and final releases.

The Development Team's Roadmap is updated at the beginning of each release cycle by the release team. It includes

1. Detailed schedule of release dates and freeze points.
2. List of modules and external dependencies.
3. Reference to all the tickets considered for the release.
4. References to the new feature proposals.

However, triggering the link to the Roadmap at the Sugar Labs wiki presently leads to an empty page, apparently indicating development has gone into a bit of a dormant state for the project

Project Anatomy Activity - Sahana

• Community -- 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?

1. Developers -- This can be in the form of contributing code, but also in becoming involved in what the project calls "blueprints. These blueprints apparently comprise the software design, as opposed to what the "designers" do in the project (described below)
2. Testers -- The project describes testers as "non-technical users" who want to contribute to the project by doing quality assurance.
3. Designers -- This refers to "graphics designers", not design from the perspective of software engineering. That being said, there is a caveat that ultimately it would be best if the "designers" could contribute their work in the form of HTML and CSS

• Tracker -- How is the information here different than the information found on the Sugar Labs tracker page?

Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Tickets are characterized by a Summary of the problem, the software Component to which the issue belongs, the Version (trunk or other branch), the Priority (major or minor), the Type (bug or enhancement), the Owner, the Status (new, accepted,assigned), Created (date reported). The information here is similar to that on the Sugar Labs tracker page. However, the Sahana project then goes on to offer a much deeper level characterization of the issues (e.g., "Easy Bugs for Beginners").

• Repository -- http://eden.sahanafoundation.org/wiki/InstallationGuidelines The installation guidelines begin 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. Can you determine from the information provided here whether the project uses a web-based common repository or a local repo?

The main repository is at github. Hence, like Sugar Labs, the use of git version control implies a distributed version control system in which each developer has their own local copy of the repo with committed changes occurring in that local copy. Developers with write access to the main repository at github would then have to push their locally committed changes to the main repository at github.

• Release cycle -- The Roadmap for each version consists of a collection of what Sahana calls "milestones". Versions listed there are 0.9, 1.0, 2.0.