I realized this morning that I hadn't told the blogosphere what my graduate students have decided to work on. (I hope the fact that I realized this while cleaning crusty soap scum off a dishwasher says more about me than it does about my graduate students' choices...) In brief:
None of these are actually on my research wishlist, which probably means I'm too much of a soft touch to be a good prof. But the students seem keen (as keen as anyone can be in Ontario in February), and I think they'll all be able to invent or discover something interesting by the end of the year. Stay tuned...
- Jeremy Handcock is studying ways to visualize the history and state of software projects. His plan now is to use something like Prefuse Flare to give project members an easy way to configure a wide variety of visualizations (of a wide variety of data), then examine what they choose to view and why. This is similar to what we're hoping to do with the new ticketing system Jeff Balogh is building for DrProject, which will let each project configure whatever fields they want in tickets---once enough people have done so, we hope to reverse engineer their actual workflows from what they've decided is worth putting into tickets.
- Samira Abdi is going to use information retrieval and text clustering techniques to "thread" the events in projects' histories. Right now, for example, the history of a SourceForge or DrProject project is a flat stream of events: a change set, another change set, a ticket update, an email message, another ticket update, and so on. When we view discussions in a bulletin board or mail reader, though, most of us groups the individual items into discrete conversations. By looking at common keywords and cross-references, Samira hopes to be able to do the same to project histories.
- Carolyn MacLeod wants to figure out why the overwhelming majority of software developers don't use formal modeling tools like Alloy, Statemate, Spin, and so on. The obvious hypotheses are "they aren't actually very useful" and "their learning curves are too steep" (i.e., someone who is just starting to use them sees all the cost, but none of the benefits), but there are others related to mismatches in problem framing.