User:Nanette.veilleux
(Created page with "'''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 unusuall...") |
|||
| Line 5: | Line 5: | ||
---- | ---- | ||
| − | '' | + | ''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. | 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 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. | release is actually a structured set of release dates by which collaborators have to have made changes. | ||
| − | Sahana Eden, in comparison: | + | ''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. | 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). | 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 | ||
Revision as of 13:15, 27 August 2015
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
