civic.json for metadata #5
Comments
|
Related conversation in Chicago |
|
Here's a first draft. status should be from a set of allowed values: beta, on hold, production, etc. (Not sure what these should be) Should we limit types, needs and categories to predefined set of values? Or, perhaps we should have a set list of authorized types, but allow for arbitrary types under some different key? [ |
|
Perhaps add "socialMedia":{ |
|
Incorporated a test version of civic.json into a few repos and got all the backend stuff working to look for this file and add it to the rest of a repo's data. Check it out, it's live now at projects.betanyc.us |
|
Saw the civic.json project and the demo implementation on projects.betanyc.us. Awesome to see you guys run with this. I've been thinking about it a bit more and I'm not sure a The main idea behind tracking a list of repos via Github is to remove the need for curation and maintenance of these civic projects. Project directory sites in the past have quickly gotten stale and less useful shortly after the initial round of curation is done. I think a JSON file that needs to be manually updated is better and de-centralized, but with it the work of curation still remains and and actually becomes less consistent. So, the question I pose is: what information is missing from the Github API that will help us better organize and collaborate on our civic projects? One theme I've seen with the spec lined out by @chriswhong is a place to ask for specific skilled help (designer, python developer, etc). From my experience, these needs change all the time and are often more nuanced than a simple "we need X." To this end, wouldn't it be better to leverage the issue tracker and perhaps come up with a framework for opening and closing needs? Something like "Need: home page design." That way, when the need is met, it can be closed more naturally via conversation & commits, rather than someone remembering to update a JSON file. We could also automatically detect the license type by looking for Curious to get some thoughts on this from @fgregg @evz @jpvelez @fkh @benbalter @kfogel @GovInTrenches |
|
+1 for Github practices that help get work done and produce documentation Scratching my head on how to do elegantly that for location, categories, Data sources = url of data or identified you used to build the app or On Mon, Jan 20, 2014 at 3:33 PM, Derek Eder [email protected]:
|
|
In the spirit of having as few fields as possible, I think "bornAt" and "status" are probably not critical. Status can be inferred from recent commit history. |
|
Derek Eder [email protected] writes:
Amen -- that's the right question, I think.
Using the GitHub issue tracker API for stuff like this seems like the
There are some projects out there already to automate license detection
+1. The GitHub API is a pretty rich place, and getting richer all the -K |
|
|
|
Sorry, was responding to @derekeder via email and hadn't seen the previous post. Categories would almost need a whole separate discussion if we're doing pre-defined values anything beyond arbitrary. Perhaps we could start with 'tags' as a start-point and then add categories as pre-defined values. The hosting idea hasn't happened yet, but I'm saying it would be a possible solution to making sure somebody is always updating the entries and at least checking to make sure the projects still exist. |
|
Folksonomy -> taxonomy is a good idea, except it would be difficult to get If we were to define a taxonomy, the way to do it would be to amass several |
|
What uses does a taxonomy serve? What would be possible to do that is not On Mon, Jan 20, 2014 at 5:58 PM, Juan-Pablo Velez
773.888.2718 |
|
Finding projects that pertain to a policy area like 311/transit or type Making things easier to find might lead to more project awareness / use / |
|
Agree, bornAt isn't really necessary, I just thought it might be neat to My thoughts on status are that I would like some way to distinguish what is On Mon, Jan 20, 2014 at 4:45 PM, Juan-Pablo Velez
|
|
My thoughts on categories are that they should be more tag-like for now, When we have hundred or thousands of data points that are all tagged, we -C On Mon, Jan 20, 2014 at 7:03 PM, Juan-Pablo Velez
|
|
Good stuff. It would be useful for feature selection to come up with some user stories for how someone would use this tool and for what purpose. I'd rather work towards actually engaging people rather than making a bunch of 'it would be cool if' features. @tothebeat blogged about how he wasn't sure what project to help out on. I could see this list serving the need of "I'm a developer with X skill. What projects are out there that I could plug in to?" Are there others? |
|
Hi everyone. To second the @tothebeat request, at Code for America we get an immense amount of offers for volunteer help. With a civic.json standard and good Github Issue labels, we could easily build a tool that would filter projects on programming language, category, time commitment, and geography. With that we could offer up interesting projects for volunteers to work on. I found a rough prototype someone else built called Issuehub.io. The extra metadata adds a lot of value to that type of tool. I could be convinced either way if it should be a file in each repo or one master list. |
|
Andrew: @derekeder is working on that. Ping him. |
|
@evz and I made some changes to the hack night projects list to support a custom project-needs label. Check it out: http://opengovhacknight.org/projects.html#/?search=project needs The idea is if you need something for your project and you're looking for outside help, create a new issue describing it and add the project-needs label to it and it will show up on our list. One thing that I'm not keen on about issuehub.io is it hooks in to all of Github and looks at some very general labels. I don't know about you guys, but just because I file an issue on Github doesn't mean I'm asking for someone else to fix it for me. More often than not, it's just a reminder for me to do it later. We'll be showing this off at tomorrow's hack night. We'll see how people use it. |
|
Awesome. Cheap feedback: "projects need" bit would look better under the
On Mon, Jan 27, 2014 at 11:56 AM, Derek Eder [email protected]:
|
|
This is rad and that it's clickable and has an explanation of the need is -C On Mon, Jan 27, 2014 at 1:25 PM, Juan-Pablo Velez
|
|
Thats great. I agree that a specifically asking for help can be really Another method I've used well is having beginner labels on an issues. Then Andrew Hyder :: On Mon, Jan 27, 2014 at 9:56 AM, Derek Eder [email protected]:
|
|
Just realized you can move the projects over to the right hand size because #details |
|
I would suggest basing civic.json on Schema.org's existing SoftwareApplication schema definition: |
|
Thanks! This is very interesting... probably overkill, but a great On Tue, Jan 28, 2014 at 10:28 AM, sheldonrampton
|
|
Chriswhong, Sheldon makes a great point. We should be using an open stander. |
|
Hi everyone, just joining this discussion. You guys have put in a lot of great work over the last several months to make this a reality. I'm happy to contribute where I can. It's possible to implement an open standard such as the one @sheldonrampton mentioned by using a JSON-LD context for our civic.json files. Here's an example: {
"@context": {
"schema": "http://schema.org",
"thumbnail": "schema:thumbnailUrl",
"types": "schema:applicationCategory",
"categories": "schema:keywords"
},
"thumbnail": "*url*",
"types": [
"Dataset",
"Mobile App"
],
"categories": [
"Transportation",
"Public Safety"
],
"status": "alpha",
"schema:Place": "nyc",
"needs": [
"frontend",
"ux",
"rails"
]
}I couldn't find schema.org terms definitions for "status" and "needs", but it isn't out of the question to develop our own definitions for these - or any other civic.json terminology - to go alongside this standard. It would take some time, obviously, and may be a pre-optimization. We also probably don't want to require each developer to have to add this context to each and every one of their civic.json files, especially when nearly all of it is going to be redundant (unless we want them all to learn about Linked Data, which wouldn't be horrible). One solution JSON-LD allows would be to use context as a url, like this: {
"@context": "*contextUrl*",
"more fields": "..."
}The contextUrl would then map to a webpage where our context lives. This still requires an additional field for the developer, so its worth exploring to see if we can do all the open standards bit on the backend and then just require a specific vocabulary: "needs", "categories", "types", etc... This would allow 0 change to the current civic.json format, and we'd still be using open standards. I think it would work as long as our json endpoint had the context object. |
|
Getting into this late because there's interest in Oakland around this (holler.) Putting on my run-of-the-mill Brigade member fedora, I'm thinking through what hooking up to this involves on the user end because it seems like minimizing friction is a big part of it. It seems like the original thought was to place a (Apologies if my understanding's incorrect -- this discussion is spanning a bunch of repos, threads, and email chains.) IMHO, I'd vote for doing less, and just sticking with
I totally get the desire to make use of GitHub's infrastructure for this, but because using Issues doesn't seem to obviate the need for most of the Fundamentally it seems like it's more a substantive discussion of how we're defining "need": a concrete task to be done vs. a skill set. I worry about the former suffering from overspecification. Anyway, just thinking through this as someone who'd love to implement it in my city/brigade, and trying to sort out what exactly it will entail. cc @migurski @ondrae for your thoughts, given the work you're doing on civic-json-worker |
|
@daguar the best entry point is to read this overview of civic-json-worker and civic.json. the overall project roadmap is here. tl;dr: the goal is to describe projects with as little data entry burden as possible. that means:
And how's this being carried out?
|
|
Thanks JP & Dave, this is a super useful discussion and I think we’re honing in on an incredibly useful community resource here. FWIW, I am somewhat skeptical of the idea that meaningful needs and project description will simply fall out of existing Github features. CfA’s desire here is to have a high-quality, primary source of project-related data. Github will help with that, but it can’t be the sole source of information. I view Github metadata as one set of data that we collect to build up a database, but I want to be sure that we’re open to alternative sources: sites other than Github, projects other than code, and so forth. I’ve posted some related comments on codeforamerica/civic-json-worker issue 14 and 13. |
|
@migurski No argument there. "Get everything from Github" was just a @chriswhong Can you close this issue so we can official move the discussion |
|
Donezo |
Develop a standard schema for civic.json to add non-github metadata to civic app projects.
The projects page can look for civic.json in the root of every repo to add things like:
-Tag for in-progress, alpha, beta, complete
-Tag for needs (I need a UX dev, I need a rails guru, etc)
-Tag for sector (transportation, housing, government, council)
Please respond to this issue with ideas for what should be included in civic.json
The text was updated successfully, but these errors were encountered: