search

BetaNYC / civic.json

A specification of the civic.json metadata standard for civic technology projects
47 stars 17 forks source link

Updating civic.json to be more widely usable #21

Open emanuelfeld opened 8 years ago

emanuelfeld commented 8 years ago

@stvnrlly (Code for DC co-captain) and I (civic tech fellow in DC government) have been working on an reworking of civic.json. The idea behind it is that existing spec is:

  1. Geared toward projects created outside of government (politicalEntity is not the creator)
  2. Is not comprehensive enough that it could be hosted elsewhere (i.e. a registry) and made more easily discoverable
  3. Certain other fields, like license and repository, would help with reuse and are required in other package standards (e.g. package.json and setup.py)

Our proposed schema is here: https://github.com/DCgov/civic.json/blob/master/schema.json With a builder and validator here: http://open.dc.gov/civic.json/

JSON files filled out according to this schema are backwards compatible with BetaNYC's civic.json standard in that all of your required fields are also required in all (with the same naming).

I see #14 is still open, but wondering at your thoughts @chriswhong, @seanluciotolentino, and others on a PR?

stvnrlly commented 8 years ago

For a little bit of background, this evolved out of a discussion that started with an attempt to update Code for DC's current flavor of civic.json following a year or so of usage. That PR is here: https://github.com/codefordc/codefordc.github.com/pull/170.

therebelrobot commented 8 years ago

+1 to the expanded spec, though not necessarily needs being omitted. That's a piece that's designed to bring new blood to the project, and something at least code for san francisco would use heavily.

emanuelfeld commented 8 years ago

Interesting. It seems that for Code for DC projects that field quickly becomes outdated and doesn't reflect current needs. My stance (perhaps @stvnrlly has a different one) is that its role is better served by the proposed 'keywords' field and by project pitches at meetups.

stvnrlly commented 8 years ago

Thanks for the feedback, @therebelrobot! As @emanuelfeld said, our experience has been that teams often forget to update needs as the they change. My hope is that the field can be replaced by labelling GitHub issues, which are more likely to reflect those needs and be visible to newcomers. (We're also hoping to encourage newcomers with help wanted tags.)

However, it's possible that there's a way to encourage civic.json updates that we're missing, so let us know if there's something that's worked in other groups.

dirkkelly commented 8 years ago

I like the idea of attaching the needs to the issue in that it creates a tangible set of work that can get people engaged. I also find I never keep my needs up to date, and instead find myself referring to open issues.

On Sunday, January 31, 2016, Steven Reilly notifications@github.com wrote:

Thanks for the feedback, @therebelrobot https://github.com/therebelrobot! As @emanuelfeld https://github.com/emanuelfeld said, our experience has been that teams often forget to update needs as the they change. My hope is that the field can be replaced by labelling GitHub issues, which are more likely to reflect those needs and be visible to newcomers. (We're also hoping to encourage newcomers with help wanted tags.)

However, it's possible that there's a way to encourage civic.json updates that we're missing, so let us know if there's something that's worked in other groups.

— Reply to this email directly or view it on GitHub https://github.com/BetaNYC/civic.json/issues/21#issuecomment-177678028.

therebelrobot commented 8 years ago

My hope is that the field can be replaced by labelling GitHub issues, which are more likely to reflect those needs and be visible to newcomers. (We're also hoping to encourage newcomers with help wanted tags.)

That does sound like a more sound method of engagement. I'll see how we can apply that better in cfsf for sure!

reganking commented 7 years ago

Hi, I'm working in the Sacramento brigade and was directed to this discussion regarding project tagging using civic.json. Are there any reference projects demonstrating how we might use this data for better discoverability of projects outside the "coder" realm? For example, if I want to direct a local city official to a site to search Code for America projects that provide models for "mobility" solutions.

stvnrlly commented 7 years ago

@reganking Project tagging across the network is really not consistent, so results may not be super useful, but Code for America built http://brigade.codeforamerica.org/brigade/projects for that sort of purpose.

reganking commented 7 years ago

@stvnrlly thanks for pointing that out! -> http://brigade.codeforamerica.org/brigade/projects?q=mobility ... will also dig more into the http://api.codeforamerica.org/api/