1. Describe your organization. Monotone is a distributed version control system. We emphasize robustness, and inventing whatever crazy stuff we have to to avoid compromising on usability and power. 2. Why is your organization applying to participate in GSoC 2007? What do you hope to gain by participating? Speaking personally, I (Nathaniel) feel I owe a tremendous debt to the FOSS community. Ten years ago, I wanted, in a yearning and hungry way, to understand how people came _up_ with these programs I saw, these elegant codes and clever designs and shipping software. Now I know, I can do it myself, and I learned it all through participation in FOSS communities. So now, I owe it to the next group of kids to give them that leg up, show them the way... To me, a project leader especially is always acting on two levels -- on the literal level, critiquing a design or telling someone off for forgetting to write tests for their patch or whatever -- but also on a teaching level, where you are also saying "here is how you critique a design, and here are the things that are important and the things that can let slide to be fixed later", "here are the things we value around here". You can learn some theory and the basics in school, but this kind of fuzzy-yet-critical understanding of relative trade-offs and community values can only come from being a member _of_ such a community... so my goal for SoC, at this point, is to bring new members into this community, get them working alongside more experienced people, and get them to the point where they are thinking in terms of "us" instead of "them". 3. Did your organization participate in GSoC 2005 or 2006? If so, please summarize your involvement and the successes and failures of your student projects. Yes, both years. 2005: We had 3 students, one who was new to FOSS entirely, one who was experienced with FOSS but new to monotone, and one who was an existing developer but working on a special large project for the summer. All were successful by the letter, but at least somewhat disappointing -- in one case (the student new to FOSS), the student accomplished their goal, but it turned out to be a less interesting goal than expected. It was something useful for us, but I don't think they actually got as much out of the program as they should have, and we really struggled to get him to participate in the broader community, mostly unsuccessfully in the end. In the other two cases, the students accomplished their goals, but by the time they were done, it was no longer as clear that the goals were as interesting as when they started -- the rest of the project had moved on, somewhat. The other student who was new to monotone did not become a regular contributor after the end of the summer. 2006: We had 4 students. At this point we were still thinking partly in terms of what work we could get done through the program (which I now think was a mistake), so we picked two students who we knew had a great deal of experience with FOSS development (one new to monotone), and two who had no experience. After our issues in 2005, we were much more careful setting up projects, and both experienced developers were very successful, produced awesome stuff we are using now, and the one who was new to monotone has continued to contribute regularly (including coming to our big summit last month). The inexperienced students also had good projects, but there were more problems. One dropped off the face of the planet -- our entire contact with him the whole summer was a phone call (after getting the phone number from Leslie, since he was not answering emails), during which he assured us that his ISP would be reconnecting his service on Monday, and he would be around from then on. He never did appear, or even answer his phone again... this was unfortunate, but I guess there wasn't really anything we could do. The other student resulted in the most frustrating situation -- he needed a great deal of help, and just before SoC officially started, the person who had volunteered to mentor him announced that he no longer had time for monotone and disappeared. Even more unfortunately, it was a project outside our normal area (writing an Eclipse plugin), so we had no backup mentor available. I eventually had to teach myself Java and Eclipse so that I could give him guidance and set milestones; but it turned out that even though he wrote a really excellent application, he was simply quite clueless about coding, and could not accomplish even the simple tasks he attempted. This year we only listed projects that have backup mentors, and have tried to make our application process more informative for us. 4. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? N/A 5. Who will your organization administrator be? Please include Google Account information. Nathaniel Smith, address@hidden 6. What license does your project use? GPL v2+ 7. What is the URL for your ideas page? http://venge.net/monotone/wiki/SummerOfCode2007 8. What is the main development mailing list for your organization? address@hidden 9. What is the main IRC channel for your organization? #monotone on irc.OFTC.net 0. Does your organization have an application template you would like to see students use? If so, please provide it now. Yes (also included on the ideas page): --- begin proposed application template --- (If you have any questions about this application form, you can try #monotone on irc.oftc.net via IRC or address@hidden via email for general questions, and address@hidden for private questions.) BACKGROUND: Who are you, beyond some characters on a screen? Tell us a little about yourself. Why are you applying to SoC? What do you hope to get out of it? Why are you applying to monotone, instead of some other project? What about it appeals to you? We would very much like to read some code, even if it just for a school project or whatever. Please give a URL for some code you have written in the past (alternatively, email a .zip or .tar.gz file to address@hidden, and note here that you have done so): Have you talked to us already, for instance on IRC or the mailing list? If so, what nick/email did you use? (This is to help us match up the people we remember talking to with the apps on Google's site.) LOGISTICS: What is your work schedule this summer? In particular, when do you anticipate starting work, will you be gone for any time during the summer, and roughly how much time do you anticipate spending on Summer of Code work each week? How can we contact you if we have questions about your application? Please include any or all of IRC nicks, email addresses, IM screennames, phone numbers, whatever you feel comfortable giving us (we will not make them public) and will allow us to reach you. We know that there is a lot of writing on our Summer of Code page at http://venge.net/monotone/wiki/SummerOfCode2007 , but we wouldn't have written it all if we didn't think it was important. To show us that you've read that page, what is the magic word that is mentioned in parentheses at one point in the text? PLANS: Please list the projects you plan to work on this summer, if accepted. At a minimum, this list should include what the projects are, how long you anticipate each will take, a breakdown of where that time will go, and what results you will achieve at each stage: Please list some places where the schedule you just gave could run into problems. Which do you think are the most likely, and what will you do to adjust if they do occur? Final question: Why should we choose you to receive money for doing the above work, rather than some other student? --- end proposed application template --- 11. Who will be your backup organization administrator? Please include Google Account information. Matthew Gregan, address@hidden 12. Who will your mentors be? Please include Google Account Information. Nathaniel Smith -- address@hidden Matthew Gregan -- address@hidden Matthew Johnston -- address@hidden Jack Lloyd -- address@hidden Thomas Keller -- address@hidden and likely a few others as well that didn't get their google account info to me in time. 13. What criteria did you use to select these individuals as mentors? Please be as specific as possible. Being a small project, there wasn't much formal process involved -- they are all people who are already in our community, I know can be trusted, and they expressed interest in participating. 14. What is your plan for dealing with disappearing students? There isn't all that much that can be done with a disappearing student -- we will try to contact them, but... Talking to Leslie last month, she suggested that this year it will be possible to drop students before the first payment, if they are not showing signs of existence. I haven't seen this confirmed or elaborated on the SoC site, but assuming it is true: this seems like an excellent idea to us; and it fits into our Crazy Scheme this year of drawing in students by having them sign up for series of smaller projects rather than one giant one. The smallest projects are basically trivial, and designed entirely to let a new developer work through the basic mechanics of writing and submitting a patch -- so we anticipate requiring that students have show at least some progress on this first basic project by the start date of the program. Or something roughly like that. This should make the worst form of disappearing students quite clear up front... 15. What is your plan for dealing with disappearing mentors? We have a few levels of fallback, here. To start with, we're not going to accept any students without being sure that there are at least two people qualified to mentor their projects -- several ideas were eliminated from our page because of this. And, of course, I will make sure (and will also make sure that backup-admin Matt makes sure) to keep track of how projects are going and thus be able to step in or find someone else to step in, if things go wrong. (It helps here to have a small project, where everyone mostly keeps track of everything.) Finally, because we are structuring students work as a series of smaller projects, if the worst case scenario happens and they somehow *cannot* finish the project they are working on, they can e.g. skip it and go on to the next one they were planning to do. 16. What steps will you take to encourage students to interact with your project's community before, during and after the program? We require students to subscribe to the mailing list and send weekly progress reports; we also strongly encourage them to become permanent lurkers on IRC. Finally, in our experience the main time interaction happens is when someone has an idea or a patch that they have finished and need to work out the last kinks in; by setting students up to submit work in smaller batches and starting very early in the summer, we expect that they will almost immediately start experiencing this kind of direct interaction where they have a direct stake. Then if they end up doing it a few times, that will give them enough practice that it starts feeling natural, and having smaller patches landed in mainline along the way should also let them build up some pride and feeling of ownership as they go, rather than waiting until the end... So, basically, the standard first-hit's-free gradual-buildup-of-addiction model. 17. What will you do to ensure that your accepted students stick with the project after GSoC concludes? Try as hard as possible to get them involved in the community before GSoC concludes (see #16).