If you're not already a part of the POSSE, none of this will make sense to you. So, I'll give you the chance to bail out now ...
Question 1 (what activities do you want to use FOSS for): let me refer you back to my first blog entry, where I talked at length about the Kettering University "Culminating Undergraduate Experience" (hereafter, "thesis project").
Question 2 (how does this get structured): well, let's give it a try here:
- Learning Outcomes: these are already determined (in a broad sense) by the Kettering CUE format:
- The project has to be of value to the employer (in this case, the developer/user community). Most FOSS projects seem to have lists of things that "need" doing (bugs or enhancements) that would testify to this easily.
- The project has to be phrased as a problem rather than a solution. Again, not usually a problem ... most bug-tracking software seems to start from statements of problems rather than well-formed solutions.
- The project needs to use the student's professional skills. This will take a little bit of work during the topic selection phase (e.g. a project that is "merely" cleaning up code might not qualify), but doesn't seem insurmountable.
- The project needs to be completeable in a reasonable time frame --- typically, 3-6 months. Again, topic selection will be important here, but that doesn't seem like a huge factor.
- Prerequisite Knowledge Needed: mostly, the student will need to dive into the selected FOSS community and learn enough about it to understand how it works. Frankly, a lot of the stuff that we've been doing as part of the POSSE homework would work well here.
- Time Required: well, if this really works the way I'm hoping, the amount of instructor time involved should be de minimis --- mostly serving as a consultant/guide to the student as she goes through the process of learning about the community, finds a project, and then seeks approval. Calendar time, as mentioned above, should be something like 3-6 months, but that can be flexed a bit, depending on how we define the "end" of the project (see below).
- Input Required From Community: I can see two types of input that would be important. The most important, initially, would be in determining a "valuable" project to work on; as noted above, I think there will be enough information about that in the community documents to help figure that out. The other form of input would be some sort of "evaluation" of the work at the end of the project --- that doesn't have to take the form of formal evaluation documents, but it'd be nice to have some sort of evidence from the community that the work performed was of quality. A merge into the main project would be the ultimate evidence of approval, but there should be other forms of approval as well that would serve. (E.g. the student takes an enhancement request and fully implements it, and the community uses that implementation as part of its decision to abandon the idea.)
- Contribution Back To Community: this will depend on what topic is chosen, but it can take any form that the community finds useful. A feature enhancement is the obvious use case here, but I could see other contributions reaching the level of "significance" needed for a thesis (e.g. a bug fix of a particularly nasty bug that requires substantial rework, or an overhaul of documentation that requires understanding a substantial code base).
- Assessment/Grading Approach: this is both easier and harder. The "good news" is that the Kettering thesis project is graded on a pass/fail basis, so there's no need for finer-grade assessment metrics. (There is an additional grading option of "pass with distinction", which is totally subjective.) The "bad news" is that there's still some need for the thesis advisor (i.e. me) to have some ability to review the project and judge that the work is "worthy". Community input would be very helpful here. (This is probably something that I could use some help with at the workshop.
- Questions/Concerns: mostly, thinking about project evaluation (see items 4/6 above).
- Stumbling Blocks/Barriers: again, see above.