GSoC Proposal
Title: Project Tools for Grassroots Activism
Proposal By: Auzigog
Available at: http://auzigog.com/gsoc-proposal
Groups.Drupal.org posting: http://groups.drupal.org/node/60118
Overview
This set of tools will allow grassroots activists to better organize projects and campaigns and will also be useful to end-users working on almost any type or project. Existing tools for Drupal are lacking key features, often not very user-friendly, and almost never packaged for easy setup. I will address these problems by:
- Adding functionality to existing task tracking modules
- Creating the capacity for subgroups
- Allowing for discussion listservs to integrate seamlessly with groups
- Creating a module to plan, track, and document meetings
Description
Problems
After surveying 30+ activists regarding the largest challenges they face, I found that the majority need a project management tool for three things:
- Holding volunteers accountable for tasks
- A central place for all documents, spreadsheets, listservs and other tools
- The ability to add and track members one time and have that reflected everywhere (organization/project member lists, discussion listservs, wiki, etc).
There are many tools available in the Drupal community that provide parts of those solutions. For a variety of reasons, those tools are not sufficient:
- Some of the features do not exist yet
- Existing tools are not usable and intuitive
- Existing tools do not come packaged for easy setup
For these reasons, most activists use Google Docs, Google Groups and Google Sites to organize their projects. When working on a campaign full-time, these tools become hard to maintain. These tools are very intuitive, but lack overarching organization and connectivity.
Solutions
What’s needed is a project management tool that is feature-rich and intuitive/usable. Existing tools in the Drupal community largely address one or the other, but not both. I hope to address the three problems mentioned in the previous section as follows:
- Features
- Task management needs to be focused on average users, not software developers. The tool needs to track not only the person/people executing the task, but also the person who is who holds them accountable for that task
- Members & Groups Most organizations have hierarchical structure and adding a person to a sub-group in reality usually means they need access to a variety of other information from the larger groups above them.
- Communication Discussion listservs are a key form of communication for most
- Meetings are abundant in the life of an activist. They need a tool to keep draft agendas and template agendas, store and search through notes, and convert “action items” from notes into tasks.
- Usability
- Developing these tools for Drupal 7 address the majority of the usability issues because of all the UX work that has been done for Drupal 7. Additionally, modules developed for this project will be more intentional about creating an experience for users, not developers.
- I am seeking a usability experts to be a co-mentor (or advisor) for this project so I am able properly address usability issues with tools I am modifying, instead of just taking my best guess.
- Packaging
- Packaging all these tools up into multiple features that will allow for the maximum amount of added value for target users (activists and organizers).
To create this tool, I will modify/extend a couple modules and create a couple others. Ultimately, these tools will result in a set of features that have are configured with maximum connectivity to increase accessibility to new as well as existing Drupal installations.
Features & Deliverables
Tasks
- Case Tracker is the most prominent existing task tracking module that is focused for non-technical users rather than software developers.
- Per the advice of the maintainer (jmiccolis), I will begin by completing the Case Tracker 2 code for Drupal 6. Porting it to Drupal 7 afterward should be trivial. Then I can base my other modules on the updated code.
- I will create a casetracker_timeline.module that will allow for bulk creation, viewing, and editing of nodes in a timeline view to facilitate backwards planning of campaigns/projects.
- Option 1: Grig approach
- Columns will act as units of time (days, weeks, months, etc)
- Rows will be for realms of a project (recruitment, logistics, media, content, etc).
- Cells will contain any number of task titles. Other fields of the Task object wil be accessible via the normal node edit form.
- Option 2: Timeline Approach
- A more dynamic method would be to integrate with the existing timeline module (based on the SIMILE project). This could display timelines. There is a risk that it would be overly complex, but it could also be more fun and intuitive to use. Editing would still occur in a simple grid.
- Using this approach could result in timelines that are similar to gantt charts.
- Option 1: Grig approach
- A new module, casetracker_darci.module, will allow for additional fields for task due dates as well as various users who are concerned with the task in various capacities.
- DARCI – Decision-maker; Accountable; Responsible; Consulted; Informed
- Allows a user to specify all the individuals that are concerned with the task, even those who do not have an account on the system.
- Begin dates and due dates for tasks are essential for a results-oriented project on a tight schedule.
- Update existing views and provide new views that reflect the various ways that a user could relate to a task.
- DARCI – Decision-maker; Accountable; Responsible; Consulted; Informed
Members
- Organic Groups is the most popular user group system.
- I will update the og_subgroups.module for Drupal 7. This will allow for hierarchical groups that reflect the real structure of organizations and projects.
- Creating a new subgroup will allow you to specify which larger group it is “within”.
- Adding new members to any subgroup will automatically include include them in all super-groups.
- Since users will be automatically added to super-groups, there will be configuration options to specify the default permissions that user will have withing the group
- The OG maintainer, Amitaibu, suggested that once OG is updated for Drupal 7, it should not be too difficult to update the subgroups module.
Communication
- Allow for a discussion listserv to compliment each Organic Group. The result would be very similar to Google Groups. There are a wide variety of discussion listserv options in the Drupal community. Many of them use popular modules, but are hard to configure. Some are easy to configure, but are not well-maintained. Here are all of the options that I have considered. I will need more guidance and time to research to determine the correct course for this feature.
- Option 1: Update og_mailinglist.module
- og_mailinglist, code on github, discussion thread
- Pros: Functions exactly how I would design it: email-focused flow instead of web-focused flow, quick delivery, and direct links to organic-groups. Maintainer is looking for help. Discussion thread indicates a good amount of support for this project.
- Cons: Relies on specific server-side email software (Emix). Not ready for a beta release yet (although it likely will be by the summer).
- Option 2: Update og2list.module
- Organic Groups List Manager
- Pros: This module serves the exact same goal
- Cons: Very old and doesn’t integrate with many of the more common email/notifications modules. Requires perl to function on the server.
- Option 3: Mailhandler + listhandler + mailcomment + og_listhandler.module
- mailhandler, mailcomment, and listhandler are well maintained projects that relate to the goal at hand.
- A new og_listhandler module could integrate Organic Groups to these modules. Features would include: sync’d member lists and specification of group_name@example.com email address.
- This is different than option 1 because it would not rely on Drupal to send/receive mail and be usable on a wider variety of servers.
- Pros: Integrates best with existing popular modules. Minimal amount of work.
- Cons: Builds another “listserv for organic groups module” when some already exist, although it is clear that they are not ideal.
- Option 4: Mailman
- mailman_groups accomplishes a similar goal
- Pros: The module would just need to be updated for Drupal 7
- Cons: Mailman is heavy and can be cumbersome to use, which defeats one of the primary goals of this project
- Option 1: Update og_mailinglist.module
Meetings
- I will create a new meetings.module for scheduling, planning and documenting meetings.
- Reminders
- Messaging Framework integration to allow for notifications and reminders of meetings.
- Agendas
- “Working agendas” that can be updated by participants when they realize new items that need to be discussed as the meeting approaches.
- Template agendas to encourage proper meeting planning and reduce the effort for meetings that have similar formats.
- Each agenda item will be an object that can be dragged in the list and to different levels in a hierarchy, essentially creating a bulleted that is easy to manipulate.
- Notes/Minutes
- Associate notes with the meeting.
- Assign the notes their own taxonomy terms.
- Possible: Allow certain “next steps” items from the minutes to automatically transform into tasks in Case Tracker.
Example Uses
Some examples of how these tools could be used by activists and by other members of the Drupal community include:
- Tasks
- The director of a community group could create tasks for each member of the group. By specifying the user as “responsible” and themselves as “accountable,” he or she can remember to check in with the member to ensure the task was completed as the due date approaches. Targeted reminders will allow both the director and member to keep track of their tasks, but not be so invasive that the reminders are ignored.
- Members & Groups
- A community group with many layers complexity (entire organization, campaign groups, teams withing campaigns) could add a user to the lowest group and be sure that the user is automatically added to the larger groups. This would allow them to simultaneously give the user access to the listserv, wiki (documents), and other resources for each level of the organization.
- Meetings
- An office of employees could have access to the agenda for a meeting happening the following week. They could add agenda items instead of forgetting them, and all workers could be prepared for the items that will be discussed. If an employee misses the meeting, they will be able to find and review the notes with ease, and see what “action items” came out of the meeting.
- Combined
- While kicking-off a a couple new projects, an organization will likely be recruiting and planning the projects at the same time–this is likely a very busy time for the organization. Temporary working groups (sub-groups) could be created beneath the main group for the organization.
- Two different “project plan” working groups could arrange meetings to backwards plan the entire project, starting with the end goal and working their way back to the current week. As members of these working groups think of tactics, events, and aspects for each project, they can add it to the working agenda for that meeting. When the meeting happens, they can use the backwards timeline module to enter in the goals for each realm and the tasks for each week. When they are done, all the tasks will be visible in timeline format as well as their individual task lists.
- The recruitment working group could have meetings with a working agenda. The notes for their meetings could be accessible to just their members or the whole team if their group was public. They could use existing Drupal modules to maitain a wiki with a script that they will use to talk to potential new members of the group while recruiting.
- At the kick-off meeting, they can have a sign-in sheet to collect contact info. During the meeting, they will assign all members a small task to complete before the next meeting, so they feel a desire to come back. At the end of the day, an account can be created for every member who attended the meeting. A sub-group can be created for each project that is being launched. Adding a member to a sub-group will automatically add them to the main group. They will automatically have access to the appropriate listservs, wiki pages and task lists.
- The next day, each project leader can use the listserv associated with their group to welcome the new members and provide some information on how to use the project tool to track their tasks and communicate with other members.
- Over the course of the week between meetings, project leaders can see all of the tasks that they are holding people accountable for as well as the tasks they are responsible for themselves.
- The two working groups can then dissolve as members take active roles in each of the projects.
Community Benefits
In a world facing a huge number of challenges, we need to maximize the effectiveness of our efforts to solve these problems. Technology offers many tools in this regard. By filling a gap in the project management realm with these tools, organizers will be able to spend less time sorting through documents and toying with spreadsheets, and more time carrying out their projects. The tools proposed here offer specific solutions and drupal offers the flexibility for these to be used in a variety of contexts.
While activists are the target users, the tools proposed here are applicable in a wide variety of situations. The vision of activism is the primary motivational factor for this project, but the tools are all applicable in many other situations. For example, the meetings module is something almost any group of individuals could benefit from.
This project is fascinating to me because it helps provides an elegant technological solution to real-world problems facing activists today.
Related Work
Open Atrium
This project has obviously similarity to Open Atrium, but it does not overlap with OA at all. All of the features proposed here compliment and extend functionality in OA, but are desirable to anyone in the Drupal community. It is likely that non-technical end-users would choose to integrate the features from this project into an installation of OA because of the added ease-of-use that OA provides. Because of the way these tools will be packaged, it will be easy to use them with OA or with a standard Drupal installation.
CiviCRM
CiviCRM is very well suited for non-profit organizations that have donors, email blasts to supporters, and large events. The tools that will be created are focused on grassroots organizations running projects. These are primarily project management tools, whereas CiviCRM offers organizational management tools. Again, these tools would likely compliment efforts in CiviCRM very nicely and efforts will be taken to ensure that none of the tools are incompatible with CiviCRM components.
Other References
Here are some of the projects and pages that I explored while doing research for this proposal. Most of the links are spread out int he proposal, but here are some that make it didn’t though.
- Scheduling meetings
- Symantic tagging in WYSIWYG editors – Potentially could be used to convert “action items” in the notes to tasks.
- Google auth – Potentially allows for an easy migration from a Google-oriented suite of tools to the tools proposed here.
- How Drupal Will Save the World
- Exportables & Strongarm – To help make it easy to export the features.
- GOTV for CiviCRM – A related proposed project that could compliment these tools nicely, once completed.
Feedback & Testing
Many of the groups I am involved with will continue to be active over the summer. I intend to have some of these groups use these tools for actual projects/campaigns as they are being developed. In that way, it will be easier to minimize the lag between time between when the feedback is given and when the appropriate changes are integrated. I estimate that I can get approximately 10 people to actively use the tool during development. I imagine the feedback process will be informal and fairly constant, so there does not need to be extra resources devoted to large surveys or something similar.
Timeline
| Fixed Dates | Deliverables | Rationale | |
| April 26-May 23 | * Examine codebase for existing modules that I will be extending/modifying. * The Case Tracker 2 code is the largest codebase that I will be interacting with, so I will need to examine it very closely. * Meet Drupal community members. * Discuss plan with mentors. * Research converting modules to D7 |
||
| May 24 (Week 1) | * Begin coding | ||
| May 31 (Week 2) | * Dead Week | * Subgroups | * Other elements depend on subgroups, so it should be done first. |
| June 7 (Week 3) | * Finals Week | * Finish Case Tracker 2 code for Drupal 6 | * jmiccolis (the maintainer) suggested that this be done first |
| June 14 (Week 4) | * Update Case Tracker 2 to Drupal 7 | * Case Tracker 2 is a large code base, so updating it to Drupal 7 would take at least a couple weeks. | |
| June 21 (Week 5) | * Tasks: DARCI fields * Tasks: Begin & Due Dates * Tasks: Update views |
* Adding fields should be easy once the code is updated. | |
| June 28 (Week 6) | * Tasks Timeline: Edit mode | ||
| July 5 (Week 7) | * Tasks Timeline: View in a simple grid or a SIMILIE timeilne | * Would need to determine which approach based on feedback from mentors | |
| July 12 (Week 8) | * Midterm Evals Due | * Meeting Notifications * Meeting Notes |
* These should be relatively simple aspects since they integrate with existing modules (Notificaitions and Fields) |
| July 19 (Week 9) | * Meeting Agendas: Working agenda * Meeting Agenda: Template Agenda * Meeting Agenda: Dynamic, draggable, hierarchical |
* Most of these elements involve only a bit of coding on top of functionality that Drupal already offers | |
| July 26 (Week 10) | * Discussion Listserv | * Length of time will depend on which of the options I pursue | |
| August 2 (Week 11) | * Slack week in case anything ran over |
||
| August 9 (Week 12) | * Packaging into features | ||
| August 16 (Week 13) | * Final Evals Due | * “Pencils Down” * Begin cleaning up code * Finish writing tests * Finish improving documentation on drupal.org. |
Mentors
Some of these individuals have confirmed yet, but they have all expressed direct interest in possibly mentoring. I have directed them to the Google Summer of Code mentor application page. I am keeping in contact with them to confirm them as mentors.
- ultimateboy
- Lots of Drupal and Open Atrium experience
- Not confirmed
- benjamin-agaric
- Lots of Drupal experience
- Confirmed
- sechrest
- Local mentor out of Corvallis, Oregon
- Confirmed
- Usability expert
- I am still seeking a usability expert to advise me on one of the key elements of the project.
- Others
- I am very open to other people mentoring on this project if it aligns with their interests and/or skillset.
Contact Details
Jeremy Blanchard
Drupal.org Profile
Gmail Chat: auzigog@gmail.com
IRC nick: auzigog
Phone: +1-503-515-6321
University of Oregon
Eugene, Oregon
http://auzigog.com
http://wiki.auzigog.com
Background & Bio
I’ve known that I wanted to be a programmer since made a website for my sixth grade class. I was a computer science major at the University of Oregon for two years. One day I found myself in a sociology class titled “Global Inequalities” where we covered basically everything that was wrong in our world today: gender inequalities, racism, poverty, and finally environmental inequalities. I wrote my final paper on environmental harms and was able to do research on what a truly sustainable planet would look like. By the end of the summer, I realized that I needed to devote my life to something bigger than me. I changed my major to environmental studies and eventually found my way to climate activism.
I have attended a week-long training put on by the Sierra Student Coalition on grassroots activism and models that have been successful for years. That training gave the confidence to co-direct a 500 person regional conference and eventually start a wildly successful student group on the University of Oregon campus–the Climate Justice League. I attended the 2009 UN climate negotiations in Copenhagen and was a field director for a large student government electoral campaign this year. This summer, I will be a trainer at the SSC camp where I learned how to be an organizer. These experiences give me a perspective on the challenges that organizers face and they are what lead me to the vision of this set of tools. I know that Drupal is the right platform for these tools because it is free (as in “free speech,” not as in “free beer,” of course) and there are hundreds of modules that would allow a project coordinator to do what is needed for their project, instead of being forced to bring in other outside tools.
On the software side, I have been working with PHP for over four years. Most of my summer jobs have been coding jobs and on the side, I like to explore web application programming. I was first exposed to Drupal this past summer when a local electric car company, Arcimoto, hired me to launch their new website. The site included a large number of specifications that didn’t fall into the basic range of what Drupal offers, so I had the opportunity to dive into the developer side of Drupal, instead of staying strictly to side-building. I have created a handful of small Drupal sites for personal projects and I am currently assisting with the redesign of the UO student government website in Drupal, which is another great opportunity to explore the Drupal platform.
While working on the Arcimoto site, I began to meet some community members and interact on the forums. I was immediately impressed by the size of the community and the sense of unity that exists. While working on this proposal, I have had a chance to chat with a lot of people, especially the maintainers for some of the modules that relate to my project. I’m excited to begin being a really active community member this summer and continue on well after Google Summer of Code is over.
Difficulty
Medium
Last Words
Thanks for taking the time to read over this long proposal. I am excited for the opportunity to undertake this project and contribute some meaningful tools to the Drupal community specifically and activists in general. There was some debate in #drupal about whether it was better to over-scope or under-scope a proposal. I decided to aim for the middle, but I figured it would be better to have too many proposals and have some seasoned Drupal developers assist me in cutting them down rather than not having all of my ideas available. If anyone has any suggestions for how to make it more attainable in the three month period, please do not hesitate to comment here or contact me directly. Thanks!
