User:Jim.huggins

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 1, Part B, 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.

Bug Tracker Activity Responses (Stage 1, Part C, Item 2)

Part 1: Bug Reports

1. (No response required.)
2. Definitions below.
   1. ID: presumably a unique identifier for each bug
   2. Sev: appears not to be used
   3. Pri: appears not to be used
   4. OS: appears not to be used
   5. Product: the specific product affected by the bug. Lots of possible values.
   6. Status: point in the lifecycle of the bug. Observed values: NEEDINFO, REOPENED, ASSIGNED, NEW, UNCONFIRMED
   7. Resolution: appears unused, but actually shows up in the list
   8. Summary: short textual summary of issue
3. The help link provided some information; alt-text for some fields revealed other data.
4. Sort order appears to be based on status.
5. I don't see a difference based on shading ...
6. Red appears to be for critical bugs. Grey appears to be for enhancements. Black is for "normal" issues.
7. Bug 573941
   1. Submitted 2009-03-03.
   2. No discussion since 2009.
   3. Bug still appears active.
   4. Appears to be assigned to "At-spi maintainer(s)"
   5. This is a small change to the documentation --- once the correct answer is identified.
8. Bug 669597
   1. Submitted 2012-02-07.
   2. Some discussion in 2012-13.
   3. Bug still appears active.
   4. Appears to be assigned to "Control-Center Maintainers"
   5. Mostly, this is a change to the internal help documentation ... biggest issue will be identifying the proper phrasing to use.

Part 2: Collective Reports

1. (No response required.)
2. (No response required.)
3. 316 reports opened. 274 reports closed.
4. Um, pretty clear that more reports were opened than closed (316 - 274 > 0).
5. Top three closers: Matthias Clasen, Carlos Soriano, Milan Crha. Important to give recognition/thanks to those who are contributing to the project.
6. Top three reporters: Bastien Nocera, Alexander Larsson, Andreas Nillson. No overlap with closers.
7. Top three patch contributors: Carlos Soriano, Bastien Nocera, Sebastian Droge
8. Top three patch reviewers: Carlos Soriano, Sebastian Droge, Matthias Clasen. Substantial overlap with closers and path contributers.
9. (No response required.)
10. (No response required.)
11. Most bugs for braille were "normal".
12. Line, table, and CSV.

Group Participants

• Jim Huggins
• Lynn Lambert
• Nanette Veilleux

Planning an Initial HFOSS Learning Activity

Please discuss and record your group's approach for an initial learning activity. When you have a good draft description of the learning activity using the sections below, you could create a learning activity page for it by copying the template here: Learning Activity Template

Time you expect the HFOSS activity to take

e.g. # classes, # homework assignments, # lab activities, etc.

Whether the activity will be completed in class or out of class

Planning Stage 3 Activities

Meetings

<Identify meeting times. Find out HFOSS project meeting times.>

Specific Tasks

<What will various group members do.>

Resources

<List any resources that you find>

Other Notes

Prior related POSSE groups, if any: