A protocol for volunteering opportunities? Part II

by Anil Makhijani on August 27, 2008

Today, I again met with a member (Matthew Cooperrider) of the Web4Roots meetup group.  Our goal was to pare down what a protocol for exchanging information about volunteering opportunities should look like.

First a quick summary of the problem:
1) Organizations need a standard way to syndicate volunteer opportunities they create.
2) Volunteers need an easy way to search for volunteer opportunities that match their location, schedule and interests.

During our first hack at this problem, we tried to treat volunteers and organizations as completely different entities.  This time our thought process was to see if we could model volunteers and organizations in the same way.  So what is fundamentally the same between volunteers and organizations?  Both have something to offer (volunteers: time, money, experience, etc.; organizations: tax right offs, a good time, free food, etc) and both have something they need (volunteers: tax write off, recommendation, satisfaction, etc; organizations: labor, money, supplies, etc).  So in effect, every time a person volunteers, he exchanges what he can give to the organization for what he wants from the organization.  The reverse is true for organizations.  So how can we model this?

Say we have a volunteer name John, who lives in New York City, enjoys cooking, is free on week nights, and wants to volunteer for 5 hours a month. Additionally, he is only willing to volunteer for an organization that can give him a $5000 tax write off. How would the protocol represent this character?

    <quantity>5 hours per month</quantity
    <type>tax write off</type>
    <datetime>Now - Jan 1st 2010</datetime>

By the same token, say if we have an organization in New York City who is trying to redesign their website by March 1, 2009.  Furthermore, it wants a volunteer who is willing to commit 20 hours a month to this project.  In return, the organization is willing to write a letter or recommendation for the volunteer:

    <type>Advanced PHP Web Develop</type>
    <location>New York City</location>
    <datetime>By March 1, 2009</datetime>
    <quantity>20 hours per Month</quantity

Each “exchange” package can have 0 or more import and export blocks.  Furthermore, each of these packages would have to name the web service that generated the data (and a unique identifier within that service).  For example, if a client on Survv asked for help for a certain issue, Survv would create a unique URI for the volunteer opportunity before it syndicated the opportunity:

<unique id>http://survv.org/opportunities/19192</unique id>

Each “exchange” package could also have extra optional data such as keywords, tags, categories, and the name of the creator.

Categories: Uncategorized

1 Comment »

  1. I would suggestion looking at solving these problems in a broader context, to help build wider spread adoption. I’m working on an initiative to solve one type of volunteer opportunity syndication by promoting broad adoption of feeds for events. In other words, if a volunteer is going to help out at an event, then the event has attributes in common with many types of events, principally location and time. These two attributes are also the items that are missing from typical RSS/Atom feeds.

    Our vision to solve this is to develop aggregator/search software and share it via an open source license while promoting the use of markup to syndicate event data in computer readable format. Several standards have been promoted for this, including RDF Calendar (http://www.w3.org/TR/rdfcal/), Hcalendar, RSS Events, and Xcalendar (links to the last three can be found on the RDF calendar page). Google calendar has an Atom feed with Google Data elements for the location and time – this is what I’ve first supported in the eventfeed.org prototype.

    Best Regards,
    Aerik Sylvan

    Comment by Aerik — September 23, 2008 @ 9:04 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment