User:Jim.huggins

Revision as of 15:50, 20 August 2015

Jim Huggins is an Associate Professor of Computer Science at Kettering University in Flint, Michigan.

Jim's research interests include formal methods, computer science education, computing history, and computing ethics. He is also involved with the AP Computer Science A and Computer Science Principles examination communities.

Jim's outside interests include church life, piano playing, and geocaching.

Introduction to IRC Activity Responses (Stage 1, Part A, Number 5)

1. How do people interact? Informally. It appears everyone knows each other on a first-name basis. Lots of references to people not in the chat.
2. What is the pattern of communication? Mostly linear, but with occasionall overlaps due to the nature of distributed chat. (E.g. someone starts a new topic while an old topic is still underway.)
3. Are there any terms that seem to have special meaning? Lots of them ... mostly technical terms dealing with the project at hand.
4. Can you make any other observations? Darci seems to do a nice job of summarizing salient points and decisions made (as should happen in real meetings, even though it doesn't :) )

Project Anatomy Activity Responses (Stage 1, Part A, Number 6)

Sugar Labs

1. Community: Seems like things are awfully loosely organized; I suspect more people are involved than those listed. (Or, people suck at updating the membership lists.)
   1. Activity Team: 2 coordinators, 13 contributors, mailing list & IRC channel
   2. Development Team: no coordinators (vacancy noted), 4 contributors, IRC channel
   3. Documentation Team: no coordinators (vacancy noted), 2 editors, IRC channel
2. Tracker
   1. Types of tickets: defect, enhancement, task
   2. Available information: ticket number, summary, status, owner, type, priority, milestone
3. Repository: pretty clearly a web-based repository (using Git)
4. Release Cycle: roadmap is updated at the beginning of each release cycle

SahanaEden

1. Community: less emphasis on names of contributors, more emphasis on the work to be done (and how to get working on it).
   1. Developers: full step-by-step instructions on how to join the community, get the development environment, and find tasks to perform
   2. Testers: less instructions, more lists of project areas to work on. One note on ways for less tech-familiar people to get involved, but less detail on the process
   3. Designers: even less information, just a few links to areas of design need
2. Tracker: main page has various (presumably) common queries of subsets of bugs in the system
   1. Types of tickets: defect/bug, documentation, enhancement, task
   2. Available information: ticket number, summary, component, version, priority, type, owner, status, date created
3. Repository: again, appears to be a web-based repository (using Git)
4. Release Cycle: roadmap has a few milestones with key features noted. Dates appear to be slipping rather dramatically.

FOSS In Courses Activity (Stage 2, Item 4)

Okay, so, in order for this to make sense, you may want to read my blog entry which describes my intended use case.

At the moment, I've selected Mifos as my project, though that's mostly because it looks like there's lots of Java work going on there, and I haven't learned Python (yet).

So, for existing class materials, I really didn't look that deeply at other people's stuff, because it's not as directly relevant. But that's okay, because the Kettering "Culminating Undergraduate Experience" has a pretty well-defined roadmap.

The Kettering process begins by a student identifying a project which has the following four characteristics:

• The project is of value to the client
• The project is phrased as a problem, rather than a solution (i.e. the problem will require at least some level of design work to bring the task to completion)
• The project requires the student to use their professional skills (i.e. this isn't just a grunt-work assignment)
• The project can be completed in a reasonable time-frame (typically, 3-6 months of full-time effort)

So, the first assignment for a Kettering student would be to investigate the project (Mifos in this case, but it really could be anything), with the goal of figuring out a larger task to tackle. The project investigation probably should involve some of the usual on-ramps (simple bug fixes, documentation cleanup, joining the online communities) in order to become a known part of the community. At that point, discussions within the community could evolve to consider what sort of project could be "claimed" by the student.

Once a project is identified, a further roadmap would be developed, depending on the needs of the project.