User:Nanette.veilleux
Nanette Veilleux is a Professor in the Computer Science and Informatics Program at Simmons College. Simmons is a small women's college. The CS program, somewhat unusually, is housed in the School of Library and Information Sciences which, oddly enough, helps us attract young women.
Simmons undergraduate requirements include two semesters of independent learning and our students usually are involved in REU's, faculty led research or their own projects. As has been reported, women students are attracted to socially relevant projects and HFOSS will be interesting to them.
Sugar: A commonality in the various teams is the request for thoughtful committment, e.g. don't go signing up for things you don't mean to do. The bug page on Sugar had defects and (requested) enhancements, in various stage of address: accepted through new. Release and road map: the roadmap (the link goes to an empty page) seems to be an overview of schedules and tasks. The release is actually a structured set of release dates by which collaborators have to have made changes.
Sahana Eden, in comparison: Sugar had a larger structure that included an oversight board. The activities on Sahana are basically the same though: there seem to be a variety of planning activities (blueprints, etc.) that seem to ask contributors to collectively bring a notion to a specification. In comparison, Sugar had more instantiated activities rather than pre-release blueprints. In addition there are the usual large and small coding activities including original authoring and bug fixing. Post code there are activities for intentional and accidental testers. The bug fix section on Sugar was populated and it was easier to see the options for bug fixing. The roadmap for Sahana does not seem to be tied to a specific release date but is a list of tasks (fairly unprioritized) with assignments (or not).
Part B.4 -- I identified MiFos as the project of interest. It will appeal to my students who are motivated by projects they feel are socially relevant,. In addition, we attract a few double CS/management students so the finance aspect will also interest those. My plan is to use this project in a (to be resucitated) software engineering course. In that course, students will need to be able to:
- write code
- test code
- debug code
- write documentation
The students in this class will (should) know java and, if some changes we're making go well, have some android experience. I wasn't able to access many of the xcite hosted links so there may be more resources out there although the "you don;t have to be a rock star" was useful. The primary obstacle I'm going to face, common in my student population demographic, is that they will fear that their code isn't good enough to publish. I would like to develop a "practice" first assignment.
-- Related and in addition to the HFOSS projects, I'd be interested in developing a pedagogical tool that supports a FOSS-like team project but is solely contained in a class (i.e. a sandbox): that is, students in a single class (or perhaps inherited from earlier classes) get used to a FOSS like environment by creating one themselves based on their interests. Requirements will be that everyone has to do something in the following categories: code, document, test and debug This would be a "training wheels" project that could lead to students picking participation in a set of appropriate existing FOSS projects
Part B course development:
Since I'm still not sure how well these activities will play out and frankly, I haven't totally convinced myself of the virtues of jumping into the unexpected, I will probably start the class with bug checking and the documentation activities. I expect to have students coding, even if they don't contribute, by the end of the semester.
The structure of the RIT course appealed to me, although the specifics are OLPC, with which I have had bad experiences. However, the overall pacing and partial flipping of the curriculum was very useful.
'Activity 1:' Documentation: Under learning activities, Coding with Meaningful Documentation, there were quite a few useful links, ones that I will probably use in introductory classes so that students are prepared. 'Activity 2:' Test Installation: in that same part of the wiki there was a test installation activity that I think will also ease students into the world. This is definitely not thinking big ...
Part C, course planning Project based: students will be assinged teams, each team will pick a FOSS project. Begining with the documentation activity: introductory lecture/ very scaffolded guided exercises (Stream of related activities) on code samples (possibly some of their old projects). and then to identify the project they will work on, and find the opportunities to document. Homework will be assigned to a) make sure the team can find time/place to meet and that everyone is on board and b) to begin documentation
List the revised activities on your wiki page. For each activity/topic: Identify some possible learning outcomes that should be fulfilled with the activities/task. SLOs: Documentation:
- Students will be able to write documentation
- Students will be able to identify documentation opportunities on their target project.
- Students will be able to read documentation and rate its clarity, style, completeness and usefulness
- Students will be able to read code and determine what documentation is necessary.
Pre-requisite knowledge for this activity will be covered in Intro to CS and a second coding course, preferably our Computer Languages course. In these courses, students learn to write, but more to the point, read their own and classmates' code.
Instructor prep: at least 10 hours for assembling reading, finding examples and writing exercises. Students should be able to contribute in 3 hrs class time. Students will become reasonably proficient in 6 class hours. I am choosing this activity to be independent from the HFOSS community because of the uncertainty of timing. Since this project is an introductory one, support on finding very "no surprises" projects would be helpful.
The result of this activity will be to contribute to the documentation of the project. Assessment will be my review according to a rubric (not distributed to the class) derrived from the readings on documentation and will have the basic elements of good documentation on a 0-2 scale. In addition, peers will assess the products in a similar way to code reviews (only in this case documentation reviews) that I already do. There will be prep exercises that will be given feedback and peer review but no grades per se.
Issues: if the code is too compact or the code purpose is somewhat obscure wrt to the whole project, then students may not fully understand it.
