User:MSkalak
Contents |
Bio
Michael Skalak is Lecturer/Technician in Dickinson College's Department of Mathematics and Computer Science. His interests are in algorithms and pedagogy.
FOSS field trip
Part 1, Sourceforge
I looked at the games tab. There are 25247 projects in 15 different languages. The most popular ones are listed at the top of the page.
For a specific project I examined FreeCiv. It let's you play a Civilization-like game. It's mostly written in C. The project appears very active and had its last release in February. It was unclear how to tell the number or type of committers.
Part 2, OpenHub
OpenMRS is primarily in Java. It has 3.7m lines of code. The second most used language is Javascript. Of the top three languages, Java has the most comments at 32%. There are about 25 commits/month and 10 contributors/month. The top contributors have been with the project for more than 5 years, 5 years, and 2 years.
FOSS In Courses Activity
My algorithms course is a writing requirement course, meaning that students are expected to produce and edit 15 pages of technical writing in the discipline. In the past, I have had them create or edit Wikipedia articles as an option for the assignment. I would like to add writing documentation for a FOSS project as an option as well. This might be a difficult to do as writing that amount of documentation could be prohibitively difficult, particularly for a project that they are unfamiliar with. I'm going to continue thinking about ways to effectively try this idea as I go through the POSSE workshop.
Bug activity
Bug examination
2. a. ID- A unique identifying number b. Sev- Severity (blocker, critical, major, normal, minor, trivial, enhancement) c. Pri- Priority (Immediate, Urgent, High, Normal, Low) d. OS- Operating System (All, AIX, BSDI, Cygwin, GNU Hurd, HP-UX, IRIX, Linux, FreeBSD, NetBSD, OpenBSD, opensolaris, OSF/1, Solaris, BeOS, Mac OS, Neutrino, OS/2, Windows, OpenVMS, other) e. Product- The part of the program that is broken (many options) f. Status- current situation for bug (NEW, ASSIGNED, REOPENED, NEEDINFO, RESOLVED, VERIFIED) g. Resolution- How the bug was addressed h. Summary- description of bug
3. I found the information from the advanced search.
4. They are sorted by status and then assignee. 5. I could not find a pattern for shaded bugs. 6. Color indicates severity. For example, there is a red bug where it crashes when trying to print a pdf. 7. I'm examining bug 349190 It was submitted July 29th, 2006. The last discussion was June 15th, 2014. The bug is listed as "NEED", presumably because the developers want more information. It's not assigned. To fix the bug, I would need to find where and how the color scheming is coded and change it to be more flexible. The bug report suggests using theme colors.
Collective reports
3. 286 were opened and 329 were closed. 4. The general trend had more closed than opened. 5. Michael Gratton, Matthias Clasen, and Bastien Nocera. This lets you know who the active contributors are. 6. Bastien Nocera, Alexandre Franke, Simon McVittie. They're not the same, though Nocera is on both lists. 7. Bastien Nocera, slomo, and Rui Matos. 8. slomo, Nocera, and stormer 11. I generated the report for ocr. The majority of the bugs were "normal" for both the UI and "general".
FOSS in courses 2
I would like to include a FOSS option in the writing assignment for the algorithms course. As a requirement for the course, the students must produce 15 pages of revised technical writing. It also must algorithms-related, which I judge on a case-by-case basis. In the past, I have offered the option of creating or substantially editing a Wikipedia article on an appropriate topic. For this project, I think the best option would be having the student document a particular algorithm employed by a project, including what the algorithm does, how it works, what options could have been chosen, and why this particular algorithm was selected.
Prerequisite knowledge:
1. Need to know something about the project and its algorithmic basis.
2. Probably other stuff, but number 1 is vague enough to cover most things.
Time
1. Instructor prep time should be relatively low. I probably should also know something about the algorithm, which would take more time if they select something I haven't seen before.
2. The students will need quite a bit of time on the project. They know about the assignment in general at the beginning of the course, and give more explicit instructions about a month before it's due. It is probably not particularly dependent on the HFOSS community schedule.
Input from community
1. The project will not require a lot of input from the FOSS community. Some background on the algorithm would be appreciated, but not necessary.
Contribution
1. The writing could form part of the documentation for the project.
Assessment
1. Assessment could be tricky. I have a generic writing rubric that I would use, but that could be insufficient given the variety of projects. A student must individually complete the writing.
Questions/Concerns/Stumbling blocks
1. Finding an appropriate algorithm/project to write about.