Updating civic.json to be more widely usable

[emanuelfeld]

@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]

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: civictechdc/codefordc.github.com#170.

[therebelrobot]

+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]

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]

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]

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 [email protected] 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
#21 (comment).

[therebelrobot]

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]

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]

@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]

@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/