Proposal: OpenUpstate API

[stevenwadejr]

The problem pointed out by @wryenmeek in this thread is that every group is using a different tool for managing their information and events. As pointed out by @BigBlueHat, the web can remedy this.

The idea of bringing the groups under one domain didn't seem like a popular idea, there may be another solution.

I propose building a backend API driven hub of information about groups. There could be a GUI backend to add groups and a little information, but the rest could be aggregated and pulled from the web. We could easily write adapters for third party sites, Facebook, Meetup.com, Eventbrite, etc... The app could run on a cron job to stay up to date.

The system could be built to function as an API to make the information about what's going on in the upstate accessible to everyone. Whether this feeds into a calendar on openupstate.org or many other places or not, this would solve the problem of scattered groups and information.

The current environment isn't conducive to corporation or growth. By sharing information and making it easily accessible in one location, we can change that.

I believe that a system like this could be built with relative ease.

[allella]

Steven,

We did jot down a number of event related ideas on index cards which weren't directly related to a calendar. I'm not sure if we recorded those ideas, but they were insightful.

The thought was to start with the most basic step, which was getting the data for organizations and then looking at how they do events. We've already started the process of gathering organizations, and to some degree locations. https://github.com/codeforgreenville/UpstateEvents

Rather than making an event API the first step, having the API share info about organizations and locations sounds like a reasonable, and easier first step. That data is a prerequisite for any events anyway, so we'll need to build them into the data structure anyway.

I think if folks know of any other monthly or annual events then they can post them
https://github.com/codeforgreenville/UpstateEvents

As for defining the required and option organization and location schema, do we want to have a thread on OpenUpstate, or another issue on The Code For Greenville GitHub?

[stevenwadejr]

Jumping out of order here:

I personally vote for using OpenUpstate to house and discuss the API. Code for Greenville seems to be "government" specific types of projects, while OpenUpstate is anything community related.

The Code for Greenville Upstate Events repo is great, but again, I don't feel like that information fits appropriately with that organization, it should be more broad.

I still believe the idea of having organization, venue, event, etc.. information aggregated into one easily accessible API is a great idea and could be achieved relatively easily. I envision there being a small backend GUI to add an Organization and simply select one of our "adapters" (Facebook, Eventbrite, Meetup.com) and let the application pull the rest of the data from the respective APIs. This way minimizes manual effort and will help maximize automation.

A collective few can hash out the plan, purpose, goals for this application, and I'd be happy to take point on it's planning and development.

[allella]

Wyren had the events API it on the Code for Greenville agenda last month,
so people ran with it.

We could see where the events API goes on the current
https://github.com/codeforgreenville/UpstateEvents repo with the intention
of forking that code over to an OpenUpstate repo when there's something
noteworthy. Or, if someone wants to create a community API on OpenUpstate
then we can move the action there.

I'm indifferent on the GitHub account. The folks who contribute will likely
to overlap pretty strongly between the two groups.

About 6 people from the Code for Greenville self-selected to work on the
event API.

Susan Molnar, Vaughan Schmidt, Eric Mayfield, Bekk Blando, me and a couple
others talked about it. I don't have everyone's names or contact info, so
I'm trying to get the person who took down all the emails to encourage
everyone to get on GitHub.

On Mon, Jun 30, 2014 at 1:14 PM, Steven Wade notifications@github.com
wrote:

Jumping out of order here:

I personally vote for using OpenUpstate to house and discuss the API. Code
for Greenville seems to be "government" specific types of projects, while
OpenUpstate is anything community related.

The Code for Greenville Upstate Events repo is great, but again, I don't
feel like that information fits appropriately with that organization, it
should be more broad.

I still believe the idea of having organization, venue, event, etc..
information aggregated into one easily accessible API is a great idea and
could be achieved relatively easily. I envision there being a small backend
GUI to add an Organization and simply select one of our "adapters"
(Facebook, Eventbrite, Meetup.com) and let the application pull the rest of
the data from the respective APIs. This way minimizes manual effort and
will help maximize automation.

A collective few can hash out the plan, purpose, goals for this
application, and I'd be happy to take point on it's planning and
development.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[stevenwadejr]

That's cool. If there are others who want to tackle that, that's good. Just putting my ideas out there, but it seems like someone's already had the idea and is working on it. I guess we'll see what comes from it.

[BigBlueHat]

@stevenwadejr I'd suggest joining in over at the Code for Greenville repo for right now. If it needs/wants to move "under" OpenUpstate eventually, cool. If not, cool. 😁 Moving stuff on GitHub is pretty "lossless" these days.

To your initial post's point, I think the more we (all!) can do to bring good APIs, Web, media types, open data, etc, the better. Your API thoughts are good ones. I'd like to see every site in Greenville publishing some open standard data formats under a declared license (open or not) and get folks who want that data (like us) aggregating it.

Thoughts?

[stevenwadejr]

My point of really bringing the API under OpenUpstate was to keep the lines that have already been drawn clear. Code for Greenville is about doing projects that are local government related (my understanding of the group) and OpenUpstate is other community "stuff". As much as we (OpenUpstate) don't want to cross into the defined realm where Code for Greenville operates, I'm concerned that by even doing a simple events API is out of their "scope", and by going down that route, they veer off of their intended path and either don't accomplish the goals they were founded on, or they splinter and fall apart.

Also, my idea for the API is more than just events. I've actually been thinking about it and mapping it out in my head for a few weeks (before Code for Greenville's last meeting, which I unfortunately couldn't make), and I believe it would be simple to do, simple to use, powerful in information, and broad enough to expand beyond user groups and into other areas.

Can we get @wryenmeek's thoughts on this and keep the discussion here and move it to Code for Greenville if that ends up being more appropriate?

[BigBlueHat]

I can't lay claim to the scope of any other organization. OpenUpstate can certainly fill the cracks and cross the boundaries between the enteties--and well it should! Where stuff starts it's life, though, is really up to the people who gave it life in the first place.

@wryenmeek, think it's your turn to weigh in. 😃 You're (both/all) welcome to put/move/create stuff here. Everyone in the @OpenUpstate/greenville should have access to do that.

Let me know how I can help!

[allella]

Steven, to clarify on the events API, we hadn't thought to serve organization and location data via the API. That was a good suggestion and makes sense, given we'd be doing much of that org, location legwork in figuring the events to scrap.

I'm indifferent about the project host. My sense from Wryen is that Code for Greenville needs to demonstrate some chops and reputation before the sexier big data, open government floodgates open. Wryen definitely has pointed out that he wants to fix government, so it seems we'll trend that direction.

Aside from re-deployments, the projects discussed by the Code for Greenville community have been a trolley tracker, events API, social services directory. So, we're decidedly loose on the government-specific at the moment. I think the term "civic" is a bit loose, meaning both activities of the people for the town, and often involving the town administration. Though, going more specific to "bettering government" seems a reasonable expectation to set for CfG.

Being loose with Code for **** projects may be normal, as the more established Asheville group had hack projects like ride sharing. Maybe there are parameters to be set to prevent the sort of fracturing and confusion mentioned earlier.

One distinction between Code for Greenville and OpenUpstate would seem to be "code". While OpenUpstate may do things involving code, it never been a requirement. The same is probably not true for CfG.

+1 for so many people coming out to hack on things on a regular basis. I guess the trick is how to balance ushering projects and people to the best fitting group without alienating folks with "we don't do that" if there is no good home for those people at the time.

[wryenmeek]

Added Notes from meeting here:

hackgvl/OpenData#4

On Mon, Jun 30, 2014 at 12:16 PM, Jim Ciallella notifications@github.com
wrote:

Steven,

We did jot down a number of event related ideas on index cards which
weren't directly related to a calendar. I'm not sure if we recorded those
ideas, but they were insightful.

The thought was to start with the most basic step, which was getting the
data for organizations and then looking at how they do events. We've
already started the process of gathering organizations, and to some degree
locations. https://github.com/codeforgreenville/UpstateEvents

Rather than making an event API the first step, having the API share info
about organizations and locations sounds like a reasonable, and easier
first step. That data is a prerequisite for any events anyway, so we'll
need to build them into the data structure anyway.

I think if folks know of any other monthly or annual events then they can
post them
https://github.com/codeforgreenville/UpstateEvents

As for defining the required and option organization and location schema,
do we want to have a thread on OpenUpstate, or another issue on The Code
For Greenville GitHub?

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

Wryen Meek
678.701.5005
http://www.linkedin.com/in/wryenmeek/ https://www.google.com/+WryenMeek

[wryenmeek]

CfG Purpose: Build a development community, in the upstate, focused on
developing prototype applications that address civic issues.

We have a lot of work a head of us before we can begin using local open gov
data to fuel our events and projects. Things like actual gov data portals,
open data policies, and even general awareness of what open data is & why
it is useful will take time and effort to build and buy in from local
municipalities. For now we will be focused on opportunities to aggregate
community data (not gov data) in an open way (hence the CKAN project) and
make it useful to the local community and local municipalities. This will
allow us to move forward as a community (do stuff together) with out
waiting on the gov data to become available first.

For now this project (as currently conceived) is a way for CfG folks to
serve their community in a meaningful way and if successful for the tech
community, it can be expanded to accommodate other communities (like
neighborhoods & non-profits) which will be an invaluable tool for civic
organizers & planners as well. In the micro its more a social app - but
targeted at the right stakeholders it can serve civic needs too.

On Mon, Jun 30, 2014 at 5:05 PM, Wryen Meek wryenmeek@gmail.com wrote:

Added Notes from meeting here:

hackgvl/OpenData#4

On Mon, Jun 30, 2014 at 12:16 PM, Jim Ciallella notifications@github.com
wrote:

Steven,

We did jot down a number of event related ideas on index cards which
weren't directly related to a calendar. I'm not sure if we recorded those
ideas, but they were insightful.

The thought was to start with the most basic step, which was getting the
data for organizations and then looking at how they do events. We've
already started the process of gathering organizations, and to some degree
locations. https://github.com/codeforgreenville/UpstateEvents

Rather than making an event API the first step, having the API share info
about organizations and locations sounds like a reasonable, and easier
first step. That data is a prerequisite for any events anyway, so we'll
need to build them into the data structure anyway.

I think if folks know of any other monthly or annual events then they can
post them
https://github.com/codeforgreenville/UpstateEvents

As for defining the required and option organization and location schema,
do we want to have a thread on OpenUpstate, or another issue on The Code
For Greenville GitHub?

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

Wryen Meek
678.701.5005
http://www.linkedin.com/in/wryenmeek/
https://www.google.com/+WryenMeek

Wryen Meek
678.701.5005
http://www.linkedin.com/in/wryenmeek/ https://www.google.com/+WryenMeek