Sunday, April 15, 2007

Summer Plans

Lessons from Summer of Code

So, GNOME didn't accept any Tomboy-related projects for Summer of Code 2007 (Mono did accept a neat one, though). On the whole, this was not due to any shortcoming in the proposals themselves. We received 14, and several of them were very good. In fact, most of the students who submitted good proposals for Tomboy have been accepted by other organizations this year, so the end goal of getting these students involved in open source is achieved.

So what happened? Basically, I posted ideas that I hadn't really thought through, and though they might have made interesting projects, they didn't have any obvious value to GNOME as a whole. When students saw the ideas post on the wiki page, they might have thought that as long as they had the best proposal for a given idea, they would be accepted. This was not the case.
  1. Revision Control: This was the first Tomboy idea listed at the GNOME SoC Ideas page. We got 8 proposals for this idea. I would have been happy to mentor at least 3 of those proposals. But here's the thing: why would anyone use this feature? If you want revision control on your notes, you probably want it on all you data, in which case you want a system-wide revision control system, not a custom GUI in each application. The only use case I can think of where this feature makes sense is for simple or formal note synchronization (that is what I would use it for). But I failed to list this when writing the idea and its benefits, and most students did not focus on it at all. In the end, these proposals received low scores from most mentors, and the highest-rated students ended up being accepted by other organizations.
  2. Encrypted Notes: This feature represented an edge case for Tomboy. It would only be useful to users who are paranoid enough to want to encrypt a few notes, but not paranoid enough to want to encrypt their whole file system. And this set of users would also have to be really into Tomboy, since there are already applications specifically designed to store secrets. We received a good proposal for this project, but most mentors were not convinced that this would really be used by anyone.
  3. Todo/Task Lists: This was my favorite idea, and I think it had the most relevance to GNOME as a whole, but it was one of the last ideas on the wiki page, and we only received two related proposals. One proposal was so well thought out that we will probably use it in our own implementation of this feature. The student who wrote this proposal was accepted by GNOME for a higher-priority idea instead.
So what are the lessons here?
  • I (or whoever) need to only list ideas that have a clear benefit to GNOME as a whole, and that have a high probability of being supported by other mentors involved in the ranking process.
  • Any piece of the idea designed to be reusable by the rest of GNOME needs to be implemented in C, or there will be a backlash. This is unfortunate but understandable. Any ideas that violate this rule should probably be listed with the Mono project instead.
  • Most proposals will be for listed ideas. It is better to list no ideas then to mislead 8 students into writing good proposals for an idea that has no chance of being accepted.
  • Corollary to above: make sure students know that just because a maintainer is interested in seeing proposals for a particular idea, that doesn't necessarily mean the rest of GNOME will be convinced by it (and in fact, it doesn't even mean the mentor who listed the idea will be convinced by it, which, to be fair, I did state on the wiki page)
So I'm bummed I won't be mentoring anyone this summer, but really the fault is my own for getting too excited and listing inappropriate ideas. I sincerely apologize to any students who may feel burned by this.

Plans for the Rest of the Summer

So I'm finally starting to have free time for coding again (SoC and other obligations being over for me). Here are my goals for the summer:
  • Get win32 support into Tomboy for 0.8.0. I've really dropped the ball on this, and it's going to take serious work to get it ready now.
  • Make a "Note This With Tomboy" extension for Firefox or Epiphany. I have basically done this for Epiphany, but unfortunately there are some limitations when writing Python extensions for Epiphany that may lead me to switch to Firefox (which is my browser of choice, anyway). This is inspired by the cool bookmarklet you can use with Stikkit to make a stikkit of the page you're viewing.
  • Poke around with Todo/Task list support in Tomboy. It would be cool to sneak this into 0.8.0.
  • Help out with note sync for Tomboy, and make sure there is some sort of win32 support.
  • Clean up and release svnservant before it suffers from bit rot.

1 comment:

... said...

"Revision control" could be as simple as an undo/redo feature that remembers the previous states forever. Information can still be lost if you undo, change something, and then want to get back before you undid.