Proposal: OpenUpstate API #3
Comments
|
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 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? |
|
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. |
|
Wyren had the events API it on the Code for Greenville agenda last month, We could see where the events API goes on the current I'm indifferent on the GitHub account. The folks who contribute will likely About 6 people from the Code for Greenville self-selected to work on the Susan Molnar, Vaughan Schmidt, Eric Mayfield, Bekk Blando, me and a couple On Mon, Jun 30, 2014 at 1:14 PM, Steven Wade [email protected]
|
|
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. |
|
@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? |
|
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? |
|
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! |
|
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. |
|
Added Notes from meeting here: On Mon, Jun 30, 2014 at 12:16 PM, Jim Ciallella [email protected]
Wryen Meek |
|
CfG Purpose: Build a development community, in the upstate, focused on We have a lot of work a head of us before we can begin using local open gov For now this project (as currently conceived) is a way for CfG folks to On Mon, Jun 30, 2014 at 5:05 PM, Wryen Meek [email protected] wrote:
Wryen Meek |
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.
The text was updated successfully, but these errors were encountered: