Google Summer of Code 2010 Reflection

Posted by auzigog on Aug 31, 2010 in GSoC 2010 | 5 comments

Google Summer of Code came to and end last week and I wanted to post a bit about my experiences, accomplishments and plans for the future.

I went into the program looking for a way to fund my work on a program that I had been dreaming about after 2 years in the activism world. I was delighted to be selected by the Drupal community to contribute modules as part of Google Summer of Code 2010.

All-in-all, I had a fantastic experience with the program. GSoC is an amazing program to bring open source organizations and college students together and I’m happy that Google offers it. They contribute add a key element to the equation and ask very little in return. Working with the Drupal community was a pleasure.

In my proposal for this project, I set out to begin work on a project management tool for teams of activists to manage their events, tasks, meetings, groups, listservs, docs and other data related to their project. The four areas I set out to contribute to were: subgroups, more flexible task tracking, discussion listservs, and meetings. I was successful in 3 of these. All of these features were envision to be applied on top of the project management tools offered in Open Atrium, but also function well when applied stand-alone to a standard Drupal installation. These tools are meant to replace certain aspects of the Google Docs/Google Groups/Google Sites combo that are scattered and hard to manage.

I learned an amazing amount about open source programming, Drupal, and projects in general.

Learning

I used this summer as an opportunity to learn about agile programming practices. First, I was very impressed by how helpful it was to think of features in terms of user stories! It helped me write down every aspect of the program in small, bite-sized chunks. I used Pivotal Tracker to keep track of my stories. You can check out all the stories I completed (up to Iteration #9 Aug 23). Pivotal Tracker only allows you to assign points (based on difficulty) to stories (rather than bugs or chores) because only stories provided “user-visible value.” This principle helped me stay on task! I am easily distracted with things like updating the project website, making logos, and other silly tasks that aren’t programming. But when had to be coding new features to “earn points,” I almost completely avoided non-essential chores like that! I also learned a lot from talking with my mentors about how to narrow the scope of a first release again and again until you only have the minimum number of features necessary. Merlin Mann talks about this in terms of blocks in your box. You can only put so many blocks in your box (features in your application) and every time you spend a day working on that feature that is really cool and adds pizzaz to your program, you are sacrificing your ability to provide an essential feature to another aspect of the program. This concept really sank in for me over the summer.

Code

Although my original proposal was far to large in scope, I am extremely pleased with what I was able to accomplish this summer after narrowing the scope (with guidance from my mentors). Here is code that I contributed:

Meetings (alpha3): This module was created using the features module. This allowed for rapid development of CCK content types and views without digging into their APIs. I added a bunch of extra functionality (permissions, attendance, and more) inside meetings.module on top of the functionality provided by the feature portion. The current state of the module does the following:

• Adds a meeting content type that includes: agendas, notes, time, location, and invitation (if Team Notifications is installed).
• Provide views for upcoming and recent meetings.
• Allow for meeting attendance to be taken and viewed.
• Permissions to manage each aspect of meetings.
• A meeting content type with location, time, agenda, notes, and invitations.
• Views to see recent meetings and meetings that are upcoming.
• Ability to take and view attendance when the meeting occurs.

Case Tracker Due Date (alpha1): I have been looking for this feature from casetracker. I filed an issue in the Open Atrium queue just over a year ago and I’m happy that I could commit time to helping to provide a partial solution to the issue. The current state of the module does the following:

• Adds a CCK “Due Date” field to the casetracker_basic_case type.
• Adds output filters to display due dates as “today”, “tomorrow”, “x days”, or the actual date depending on how far off it is.
• Modify primary case listing table to include a “Due Date” column.
• Adds ability to filter cases by due date.
• Provides “Upcoming cases” page and block.

Case Tracker Comment Driven (alpha1): This was made to compliment the due date functionality above so that modifications to the due date could be made through comments just like every other field offered by the default case content type. Comment Driven already offered that exact functionality! The only problem was that Case Tracker and Comment Driven offered separate forms for editing fields and separate tables for displaying what had changed at the top of each comment. I used the theme layer to merge these tables/forms to make it appear as though all changes were occurring within one system.

This module can be used to modify any aspect of a case (other fields, taxonomy, etc) through comments.

Organic Group Subgroups: The goal with this module was to allow a user to define a hierarchy in among their (Organic Groups) groups and allow content and users to propagate up/down the hierarchy. For example, if I have an organization with many campaigns, and each campaign has multiple teams, I want to be able to add someone to the team level and have them automatically added to the appropriate campaign and organization groups.

I didn’t actually have to code this module! There is a long, winding history behind the Drupal 6 version of this module. I spent a while researching that history and came to find that someone had already done all the work to create a functional Drupal 6 version! bschilt had created a D6 port and posted it in the issue queue, and the maintainers weren’t active enough to notice and give him maintainer access. He had even been maintaining updates to his port of the module as Organic Groups was updated. I merely put in the work to connect bschilt with the maintainers of og_subgroups, review his code, make sure he got maintainer access, and guide him through the process of contributing his code (CVS, readme files, etc).

This kind of situation represents the true power of the Drupal community!

Patch to Features: My first patch was committed during GSoC. I was using some brand new aspects of the Features module to modify Open Atrium to fit my needs. It was hard to work with these aspects because there was no in-code documentation and I couldn’t google for a description of these newly-added hooks.

Other Impressions

I would highly suggest that any future Google Summer of Code student schedule a weekly demo with their mentors! Using dimdim (or GoToMeeting if you want to pay for it) to give a screencast to your mentors (or anyone sitting in IRC who wants to join you) is a fantastic way to keep yourself motivated through the week to produce visible results. When you know someone is going to be looking at your progress in a couple days, you code a lost more diligently.

Another suggestion to future GSoC students working with Drupal: Write a detailed proposal! Apparently no one had ever seen a proposal as long and detailed as mine. Haha.

Code was a big part of Google Summer of Code, but as bojan has already observed, the people in the community play an extremely large part as well. My primary mentors, Ashe Dryden and kevron were phenomenal. They are doing great work creating tools for teams (using Open Atrium) over at Bucket Works and Bucket Brigade. They were there to observe my weekly demos, keep me on schedule and focused and provide a guiding light when I was first getting started navigating the community. Many thanks go to them for the hours they contributed to this project. My co-mentors also provided support over email, phone and during demos to help me with large design choices (the kind I usually get stuck on for too long): sdboyer, benjamin-agaric, and sechrest.

Since a lot of my work related to Open Atrium, I found myself in the #open-atrium IRC room a lot asking questions of the good folks at Development Seed. I am deeply thankful to the many questions and words of wisdom offered by Young Hang and Jeff Miccolis when I was interacting with their modules and with Open Atrium in general. They are busy folks, but their generosity in support never ceased to amaze me (and be extremely helpful).

Many, many small problems were fielded by all the great people in the #drupal and #drupal-contribute IRC rooms. Without quick answers to pesky problems/questions that were slowing me down, I wouldn’t have accomplished nearly as much this summer. Shout outs to: heyrocker, webchick, chx, dereine, merlinofchaos, dimitri01, and many others who I’m sure I’m forgetting.

Future Work

I certainly want to continue my work on this tool. My original motivation was to solve a lot of the logistical problems that have faced the student group I co-founded at the University of Oregon, The Climate Justice League. I still want to have a working demo for us to try out when classes begin in the Fall.

First order of business is to get discussion listservs working with each group. In my original proposal, I offer four different ways of approaching this feature. Since then, Kyle Mathews has done a great deal of work on og_mailinglist. This offers a perfect duplicate for Google Groups, but only works on servers where you have root access to install specific server, which is a mild concern for me.

I also want to look into using the GData module to automatically share individuals on a google docs folder when they are added to a group.

I also need to get stable releases of the 3 modules I created this summer. For that to happen, I need testers! If you have an inkling to try out any of them out, please do and report any issues to proper issue queue. Meetings, Case Tracker Due Date, Case Tracker Comment Driven

Then I need to package it all up! I want create an install profile that extends the Open Atrium install profile. This is where the real value-added from all these modules will become visible. The problems that I am working to solve will really be solvable once these features are put together is such a fashion.

I also need to pick a name! Activism Labs is the name of the “organization” (which means just me) and I am still looking for a name for the tool that I’m developing (the set of modules and the install profile). I have a name brainstorm list here.

I am also putting together a new (and evolving) “master features list” that will hold every feature I think up (many of which won’t be implemented for quite some time, if ever). This will help me stop thinking about them constantly and will help me remember some of the nifty ones down the road.

I have been keeping a contact list in a spreadsheet of anyone who has expressed any interest in this tool so far and I plan to get a hold of everyone once I have a testable beta available! Use the contact form if you’d like to be notified when a (on an extremely occasional basis) when updates are available about this project.

Closing

I am so appreciative of the opportunity that the community offered me by accepting my proposal. I really encourage any student interested in Drupal to apply for this as their summer job. It was valuable for me in countless ways. I had the chance to work on a tool that I had been envisioning for almost a year. Thanks again to all of those who have guided me thus far!

I look forward to continuing my work on this tool and with the community!