As part of my commitment to spent the next 12 months heavily devoted to building Activism Labs, I’ve created a survey to better understand the needs of teams of activists and organizers. Your ideas will shape the initial direction that Activism Labs takes.

Click here to take the survey

I had the privilege of presenting at the PNW Drupal Summit in Vancouver this week about the overlap between Project Management, Activism, and Drupal.

I met some amazing local folks, had a chance to really get to know people, expanded by knowledge, and grew my excitement in the work we are all doing!

Below are my slides from that talk. See the SlideShare page for the slide notes.

Read on to view the slides.

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!

This article covers how to use the SimpleTest framework with a feature made using the Features module. Most of the advice here applies to anyone who is just getting started with SimpleTest and Drupal automated testing.

Since the Meetings module is almost ready for a stable release, I was forced to quickly realize how important a testing suite is. Until the module has a wide user base who is willing to test the module for me, it is up to me to do all the testing. Considering all the different states the module can be in (organic groups enabled, meeting owner logged in, various permissions, etc.) this quickly becomes an overwhelmeing task.

I dove into the SimpleTest framework to automate my tests in Drupal. It’s a very robust set of tools and it doesn’t take too long to get started with. Unfortunately, I got caught up on a few small points that I ended up wasting hours on. It was particularly difficult for me because I was releasing a feature, not a standard module. The differences are small, but they were enough to slow me down for a while.

After installing SimpleTest, patching Drupal 6.x core, and installing the Examples module, I started reading through the fantastic SimpleTest tutorial. Below are the “gotchas” that I encountered that prevented me from actually writing tests.

Gotcha #1: Module Dependencies

The first problem I encountered with the setUp() function of the module. My function originally looked like this (INCORRECT CODE):

public function setUp() {
  parent::setUp('meetings');
}

I was under the impression that this would automatically enable all of the dependencies of my feature. I was mistaken. In fact, you need to explicitly list all of the dependencies of your feature and list them in the order that you would enable them in the visual interface. For example, date_api must be listed before date because date depends on date_api. The correct code is as follows:

public function setUp() {
// Must include every single module that Meetings relies on
  parent::setUp(
    'content',
    'ctools',
    'date_api',
    'date',
    'date_timezone',
    'date_popup',
    'features',
    'filefield',
    'messaging',
    'notifications',
    'notifications_team',
    'strongarm',
    'text',
    'views',
    'votingapi',

    'meetings'
  );
}

Gotcha #2: Temporary File Directory for SimpleTest

This one isn’t specific to building a feature module, but it did hang me up for a while.

For one reason or another, SimpleTest wasn’t able to create a directory to story temporary files related to the tests. Perhaps this was because my permissions were incorrect, but after getting enough file_put_contents() errors, I did the following:

cd directory-of-your-drupal-site
cd sites/default
mkdir files
mkdir files/simpletest
mkdir files/simpletest/verbose
chmod -R 0777 files

Gotcha #3: features_rebuild()

I’m not actually 100% sure that this is necessary, but while digging through the test suite for features itself, I discovered that the following line is included in the setUp() function of the features tests.

// Run a features rebuild to ensure our feature is fully installed.
features_rebuild();

This did reduce the number of errors I was getting at one point, but now that everything is functioning, commenting out didn’t cause any of my tests to fail.

Gotcha #4: call cache_clear_all()

After talking to Young Hahn, the maintainer of features, I learned that some elements of a feature may not be loaded as expected in a SimpleTest environment because of various caching issues. I threw in a cache_clear_all() into my setUp() to cover all of my bases.

// Clear all caches so everything from the feature is recognized now that it is fully loaded.
cache_clear_all();

Gotcha #5: Permissions reset

Because of the above problem, the permission checking system inside SimpleTest needs it’s cache flushed as well. This arose for me because I was dynamically loading permissions based on the CCK fields in my feature, and since those fields were not loaded when SimpleTest did it’s initial setUp(), they permissions needed to be reloaded before I could use drupalCreateUser() (which does a permissions check along the way). Until I did this, I would get Invalid permission edit meeting purpose and so on for each field that I was adding a permission for.

To for the reset of the permissions, I added this line to my setUp() (before creating any users):

// Force a reset of the internal SimpleTest permission list cache now that the feature is fully loaded.
$this->checkPermissions(array('access content'), TRUE);

I am sure there are other systems within SimpleTest that have caching problems, so keep an eye out if you are experiencing problems. Check in drupal_web_test_case.php to see if there is any caching involved.

Other SimpleTest tips

Here are some resources I found helpful:

• SimpleTest tutorial
• Slideshow to accompany the above tutorial
• Guide to SimpleTest from Lullabot
• List of assertions
• List of API calls

Make sure you turn on verbose mode in admin/build/testing/settings. This will automatically save the HTML from any page that SimpleTest calls using drupalGet() or drupalPost().

When you’re at a loss for documentation, just read the inline documentation in drupal_web_test_case.php. That’s the closest you’re going to get to API docuemtnation until api.drupal.org supports documentation inside classes.

When you need to troubleshoot your tests as you are making them, the Drupal 6 version of simpletest offers the debug() function. Read more about debug().

Do you have any advice on using SimpleTest and Features? Post them in the comments.

My work over the past two weeks has been focused on creating the Meetings module.

The motivation for this module came from the fact that most organizations I work with have a fair number of meetings to coordinate projects, but have no sane way of tracking them. Notes are always taken at the top of a google doc, agenda items are hard to gather in advance, and it is nearly impossible to find notes from the past.

Here is a screencast demonstrating most of these features.

The current release (alpha 2) is almost ready to be moved to a stable release. Current features include:

• Track date, time, location, agenda of individual meetings
• Take notes at a meeting
• Create repeating meetings
• Invite users to meetings
• Take attendance at meetings
• Organic Groups integration for invitations/attendance
• Views to show recent/upcoming meetings

If you have a few minutes to test out the current release of Meetings, I would really appreciate any feedback you have. You can post issues to the issue queue.

To all newcomers, welcome to Activism Labs. Learn more about the project management tools that will be created here this summer.

Today, I’m launching Drupal 7 Release Date and @drupal7release to help the community forecast the potential release date for Drupal 7 based on the number of critical bugs remaining in the queue.  The idea came from a countdown discussion on Drupal.org.

After realizing that “drupal 7 release date” is the first search that Google will suggest to you when you begin typing “drupal 7,” I thought it might be good to provide a resource for Drupalers who are excited about Drupal 7, but don’t yet know that they can help it be released sooner.  So I created the entire site assuming that the majority of the users will be site builders who are eager to use Drupal 7, but have never contributed code to core or tested patches before. I provide some short, but sweet set of steps for reviewing patches on Drupal 7 to help squash bugs. (I’d love some feedback on ways to improve the set of steps to be more noob-friendly).

Here’s the front page with the projected date and many calls to action to help out on the bug queue.

There’s also an interactive graph of the velocity of critical bug fixes since march.

You can also follow the updates on Twitter by following @drupal7release.

While none of this is particularly related to the tools being created here at Activism Labs, I did feel like making this site would help the community by directing those eager for the next release in the right direction. Hopefully this makes up for the fact that I won’t be able to develop my modules in D7 this summer.

Know of a way to get more people working on the critical issues queue? Have advice for the site? Share your thoughts in the comments.

As part of my continuing effort to narrow the scope of my project plan for the summer, I have been in contact with Jeff Miccolis from Development Seed, the maintainer of the Case Tracker module and one of the lead developers of Open Atrium.

He was able to fill me in on the early plans for Drupal 7 ports of Open Atrium (OA) and Case Tracker.

Open Atrium for Drupal 7

According to Jeff, the current plan is to get a stable 1.0 release of OA out the door before any big ports or feature additions.  He said that it was “close to impossible” that there will be a stable D7 release of OA before the end of the summer.

As much as I’d personally like to see a D7 release, it is understandably hard for the OA team to base their plans around an unpredictable roadmap for Drupal core. While it may make sense for some contrib modules to pledge to have a D7 version ready the day that D7 is released, OA is a complex piece of art and it will take more time for the D7 core and contrib code to be solid enough for a port to be feasible.

This opens some interesting question for Activism Labs, which are discussed below.

Case Tracker for Drupal 7

We also discussed the plan for Case Tracker. Jeff said he doesn’t want to simultaneously maintain a D6 & D7 version of Case Tracker, and I can’t say I blame him. Maintaining two releases of a code base is a big time commitment, and isn’t always the best use of time. With limited resources, it is probably better to make a clean switch to a D7 version of Case Tracker and give it the full attention that it deserves.

He mentioned that other modules sponsored by Dev Seed that are lower in the OA stack will be updated first.  First Strongarm will be updated, then Spaces and Context, and somewhere near the end Case Tracker.

What does it all mean for Activism Labs?

The project is now faced with an interesting question:

Develop D6 modules that are more usable (via Open Atrium’s UI) or develop D7 modules that benefit the Drupal community in the long term?

My personal vision for the project is for activists to use these tools as features on top of Open Atrium because it is very user-friendly. Developing modules in Drupal 6 will result in a set of tools that are immediately accessible to non-technical users like grassroots activists.

Developing the tools for Drupal 7 means that the tools wouldn’t be usable as part of Open Atrium for an unknown amount of time (late fall? winter?) and the project could lose momentum if it the tools are not usable in a unified state when GSoC ends.

To be honest, I feel like it would be selfish to develop the tools for Drupal 6. I consider the GSoC slot to be a position of huge value to the community and developing D6 modules would not be fair to those who helped rank my proposal.  This is especially true because I stated that all modules would be in Drupal 7 in my initial proposal. That said, if I do build my modules for D7 and Case Tracker hasn’t been ported to D7, I would have one heck of a time making my task modules and timeline modules, which are key elements of my plan.

Question: Should I develop the Activism Labs modules in Drupal 6 or Drupal 7? Please leave your thoughts in the comments.

As promised yesterday, I have added a new community section to the website!

Sections of community.activismlabs.org include:

• Community Activity Page
• Issue Tracker
• Documentation

They are all a little sparse right now, but I imagine as this project gains traction, this will be the ideal places for people to contribute and find information about the work we’re doing!

I used the project management tool that I’m in love with, Open Atrium, to setup the community section. I modeled the

By the end of the summer, I hope that all of the modules/features that I create will easily integrate with Open Atrium because of it’s beautiful UI and great ease-of-use.

Questions: What is the best way to start building a small community around a small set of tools? Is creating a specific space overkill? How will it reach a critical mass?

Coding begins tomorrow for Google Summer of Code, so I’m working with my mentors to finalize the project plan.  This includes cutting back my very ambitious initial project proposal and choosing a tool track my tasks, features, and bugs for the project.

Tracking Tool: Pivotal Tracker

I evaluated a lot of project management tools on a variety of factors. The main thing I was looking for was something that was popular enough to have integration with other software development tools. I ended up selecting Pivotal Tracker, for the following reasons:

• It’s free for project of any size
• It uses a story-based system
• It works well for an agile development workflow
• I can drag and drop things :)
• Integration with many popular tools including GitHub
• There is an iPhone app (multiple apps, actually)
• Good introduction video

I spent most of today moving all my specifications for the project over to user stories.

View the user stories for Activism Labs (click on Icebox to see all of the planned features)

Question: What is your preferred project management tool for Drupal modules?

Version Control: GitHub

I plan on using GitHub to manage the source and versions of the many different code bases that I will be working on. I haven’t created all of the repositories yet, but you can track auzigog’s GitHub account to know when the projects are created.

I could make a long list of reasons why I chose to use Git, but that has already been done: WhyGitIsBetterThanX.com.  I will also be mirroring my code on a drupal.org project page.

Community Space: Open Atrium

To create a robust dialog among those people interested in activism and project management, I want to create a space for others to discuss.

I am going to install Open Atrium at community.activismlabs.org to allow for discussion, documentation, feature suggestions and more. Be on the lookout for that.

Question: What kind of community features would you like to see available?

Hooray!

This morning the list of accepted Google Summer of Code projects was announced! The proposal for Activism Labs was accepted!

I’m really excited to work with the Drupal community and build some tools that will facilitate better project management.

My primary mentor is houndbee and I will be getting help from benjamin-agaric and sdboyer.

Also, I created a twitter account to track the progress of the project: @activismlabs

If you’re interested in keeping up to date with the project, subscribe to the RSS feed.

Special thanks to heyrocker, dmitrig01 and others in the Drupal community who are helping make GSoC happen.