User:RMccleary

Revision as of 23:16, 14 June 2016

About Ron McCleary

Ron is assistant professor of computer science at Avila University in south Kansas City, Missouri. He has been at Avila for 14 years. Before that, he was Director of Corporate Information Systems for Terracon, a national engineering consulting company with headquarters in the Kansas City area. Before that, he was at Rockhurst University in Kansas City for 13 years, four of them as a computer science instructor and nine as Director of Computer Services.

Avila is a liberal arts schools sponsored by the Sisters of St. Joseph of Carondelet. The Computer Science Department offers three majors: computer science, software engineering, and a newly approved one in health informatics. Ron teaches a variety of courses that includes operating systems, computer organization and architecture, database, networking, systems analysis and design, Java, and C#.

Ron's interests and activities outside the classroom include reading, hiking, and teaching in the education program of his church.

FOSS Deliverables

IRC

How do people interact? While the meeting has a "flow" to it, because of the asynchronous characteristics of the typed responses, it is more of be a flow with ripples.

What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix? Generally, a linear flow of ideas but with a lot of small branching in and out of the current theme. It is informal. Generally, it is one-to-many, interspersed with occasional one-to-one communications; i.e. it is a mix.

Are there any terms that seem to have special meaning? Don't think I noticed any.

Can you make any other observations? At first, I thought the comments to oneself (the /me commands) were inhibiting the flow of the meeting. On further reflection, I think they add value by giving a little comic relief.

Sugar Labs Project

Roles most applicable for my students

My students come with a variety of skills and interests, so some of them may fit several roles while others may only fit one role. Some of roles seem to have some common skills required: content writer and people person seem to require good communication skills; designers and developers need to use complex programs (for programming and graphic design, respectively). The educator role doesn't seem to fit well for any of my current students.

Content writer Several of my students are good writers and have the skills to write content.

People Person Again, several of my students would be good at this role. In fact, many of the ones who could do well as Content Writers would also do well in this category.

Developer We have a two-semester Python requirement in the major to introduce our students to programming, so most of my students should do well in this category.

Designer A few of our students are doing graphic arts minors and would be well fitted for this category.

Translator We have several international students, mainly from Saudi Arabia and a few from Japan, who could be helpful here.

Use of Tracker

General instructions to submit bugs can be found at the Submit Bugs/Problems page. To submit a bug, first visit the sugarlabs page at github and look for the activity or a sugar component repository that is relevant. If it isn't clear which one is the best choice, pick the first on in the list, sugar.

You will need to be signed in to github (follow the links at the top of either page). Hit the "Issues" tab at the top of the page and the the big green button labeled "New issue" to report the issue.

The type or category of and issues will be either defect or enhancement. For each ticket, the system tracks a ticket number, a summary statement, status, owner, type, priority, and a milestone.

Repository

The project uses Gitorious, which supports distributed, open source projects and appears to use a local repos.

Release cycle and roadmap update

The roadmap is updated at the beginning of each release cycle by the release team.

The Sahana Eden Project

Community / contributing

Developers - Developers will need certain programming skills. The system is developed in Web2Py, and Python and Javascript experience would be helpful. It uses the Model-View-Controller (MVC) architectural pattern to implementing the user interfaces. Developers sign a license agreement retaining all rights to their code but allowing it to be distributed and used.

Testers - They can be non-technical, doing manual testing and documenting new test cases.

Designers - They give input about the look and usability of the application and the project web sites. The preferred, but not only, way to do this is in the form of CSS and HTML

Tracker

The tracker for this project keeps data similar to that kept for the Sugar Labs project. For each ticket, it keeps ticket number, summary statement, component, version, priority, type, owner, status, and date created.

Type can be defect/bug, enhancement, documentation, and task.

Repository

The project apparently uses a local repo.

Release cycle

Version 0.9.0 "Medway" was released five years late (in 2011). Version 1.0 "Avon" has no date set but was planned for May 2012. Version 2.0 is mentioned but with no projected date.

Explorations of forges and OpenHub

There is a lot of commonality of the facilities between the two. Both support repos, bug tracking, and various forms of communication. My impression is that the OpenHub may scale up better for large projects (but, of course, I compared a relativley small project in Sourceforge to OpenMRS in OpenHub).

Evaluation of OpenMRS

OpenMRS would be a good choice for my students. Here is the evaluation sheet on the project: File:OpenMRS Evaluation.pdf

FOSS In Courses Activity

I would like to consider activities that would fit in the second semester of my two-semester Java sequence or of my two-semester C# sequence. Two seemed to fit in that they would expose my students to large code bases:

Diagnose a bug Individually or in pairs, the students would be assigned a simple open bug (or allowed to select from a prepared list) and asked study the code to figure out the cause of the bug. I might create a peer review process so students get their work reviewed before submitting it to the FOSS project.

Test a beta or release candidate Students would download, build and test the software. This could be a team activity. Teams might be paired and compare the results of their testing before submitting it to the FOSS project.

Add a comment Each student would look for obscure or unusual code and document it. Here again, I would probably create a peer review process.