[racket] Google Summer of Code 2012 Ideas

On Mar 1, 2012, at 2:21 PM, Asumu Takikawa wrote:

> We are currently putting together an application as a mentoring
> organization for the Google Summer of Code 2012, which is a summer
> program in which Google pays students to work on open source/free
> software projects.
> 
> As part of the application, we are currently collecting project ideas
> for our "ideas page" that gives applying students ideas for projects
> that can be completed in 12 weeks. If you have any ideas along these
> lines, please contribute to our wiki page:
> 
> https://github.com/plt/racket/wiki/SoC-Ideas-2012

I don't actually have a github account, but I wanted to mention the following idea both to current Racket developers and to potential student programmers.  Could somebody add it to the wiki for me?

Summary: a DrRacket plug-in to enable real-time collaborative editing of a source file, possibly with fine-grained logging as well.  Two or more different programmers each edit the same file simultaneously, and edits one of them make show up immediately on the others' screens.

Benefits: The benefits of collaborative editing should be obvious, the benefits of the logging feature less so.  I attended a SIGCSE talk this morning on a program called CodeWave which provided both collaboration and (keystroke-level) logging, which the student programmers and/or their instructor can play back to see what process they were following, what kinds of mistakes they make most often and how they dealt with those mistakes, etc.

Requirements/Difficulty: Will need to hook into DrRacket.  Will need some kind of server, with user authentication and permissions (so a specified set of students have access to the shared file); see the project already on the Wiki about adding git support to DrRacket.

Possible mentor: I don't know.  Guillaume Marceau has done some of this, but I'm hesitant to volunteer him without asking :-)

Other:  I'm not wedded to the "log every keystroke" idea: for simultaneous editing, you want to synchronize no less often than every few keystrokes, but you might not want a separate log entry quite as often.  Which sort of inverts the git ideal: it encourages you to commit locally fairly frequently, but push to the server only every several commits.  I'm thinking of something that effectively pushes every few seconds, but only every several pushes become a distinct "commit" record.

A less elaborate version wouldn't log much of anything, but would still synchronize with a server every few keystrokes.

Stephen Bloch
sbloch at adelphi.edu