follow forks from orgas to find canonical repos

[elf-pavlik]

I participate in #c4freedom and after chatting with folks from Code for Berlin and Koduj dla Polski it turns out that most of their projects evolve in repositories outside of their github organizations. I suggested that they just fork them to their orga repositories to mark inclusion. Also this way multiple brigades contributing to same projects can signal collaboration. @KrzysztofMadejski @k-nut I guess currently cfapi doesn't understand such pattern?

[pmackay]

Or does cfapi need to expand the number of repo platforms it can be parse?

[elf-pavlik]

@pmackay eventually I would like to make it possible (but not required, not everyone needs to grow up...) for each organization to take responsibility for publishing their data. So people may need to make sure they can export relevant data from platform XYZ. So if people want to use bitbucket, gitorious, gitlab or whatever, they just need to have exporter to get data from it (preferably into common JSON-LD) or even better integrate exposing such common format into platform itself (if open source)!

[pmackay]

@elf-pavlik not quite sure I understand. Most of the data in cfapi is currently pulled from github API. If an org is using BitBucket say, then dont we need to build an importer of the same data (as far as possible) via that tool's API (if there is one)?

[elf-pavlik]

@pmackay I just look differently on we. Rather then centralizing responsibility for making adapters to all those project, event, blogging platforms I would prefer re-decentralized approach that people take responsibility for making their data available in common format. Of course everyone could help with developing various tools to it but not necessarily one big monolithic setup. Anyways, for now we still can improve handling data from github and mapping Person <-> Organization <-> Project relationships ...

[migurski]

@pmackay @elf-pavlik I think an importer would be the best way to do this. Currently, Github-specific properties are documented in the API as part of an opaque github_details object in a project. For projects from Bitbucket or elsewhere, a similar {vendor}_details object would be most appropriate.

[migurski]

…issues has a few Github-specific details that might need to be stretched for a new source like Bitbucket, hopefully not by much. I’m committed to ensuring that all API changes are backwards-compatible with respect to the spec.

[pmackay]

Hmmm, I had a decent chat with @ondrae at the Summit last week about this. I've been suggesting (at least in the doc linked to in https://github.com/codeforamerica/cfapi/issues/118#issuecomment-51720137) that the API change to support a more Linked Data style and provide a more unified front, so clients would not need to know if its github or another system that is being used. Shame we didnt get a chance to meet and discuss Mike but I'm sure you were busy!

[elf-pavlik]

@migurski in #118 I suggested evaluation of http://www.hydra-cg.com/ I also recommend this video, which can help us establish common understanting of concepts related to modern APIs - "REST, Hypermedia, and the Semantic Gap: Why "RMM Level-3 REST" is not enough" http://youtu.be/UkAt9XSOfaE

[KrzysztofMadejski]

@elf-pavlik and others: I was speaking at cfasummit to @ondrae and there exists a documented and clear way to include multiple repos of a brigade/organization (typing them by hand). So I see no need to develop anything else.

Also forking wouldn't work, cause issues are not getting forked.

I guess what you mean (i'm reading between lines) is that right now the cfapi enforces ownership of the projects, which is not quite right from github and opensource principles perspective. Tough I believe it is very right from organizational perspective to have it like that.

[migurski]

It’s true that in the CFAPI data model, projects are owned by exactly one organization. Multiple organizations can claim a project, but it will appear in multiple places in the API.

[ondrae]

Hey everyone.

We're building the CfAPI is to track and show off each organizations activities. We're trying to make it super easy for each group to be included by letting them use whatever tools they want, and we'll build the importers ourselves.

The easiest way to get a group's projects included is to just keep them all in the GitHub organization account. Realistically though most groups have their projects spread all over. They can instead point us to a CSV. We've got examples and documentation in the README. Here is Code for San Francisco's project list. Several of these aren't code projects at all and are still included.

As for the schema, in November I'm going to dig deep into json-ld and the other research you've all provided. My main goal is to keep it simple for our volunteer developers of various skill levels. One piece of research I'm still missing are examples of services that consume json-ld. Particularly civic tech projects. I think that http://hack.g0v.tw/project does, though I can't find the relevant code.

[elf-pavlik]

@ondrae JSON-LD spec became W3C recommendation early this year. Already got picked up by Schema.org & Google Actions in Inbox (just adopted by github!)

• http://youtu.be/KB94dIamAQc
• http://youtu.be/XXw8g-FbemI
• http://manu.sporny.org/2014/github-adds-json-ld-support/

Also it just became a MUST for W3C LDP spec: https://twitter.com/lehors/status/512088825888133120

And has strong support in W3C Social WG (BTW I will propose CfA as one of use cases there!) http://www.w3.org/2013/socialweb/social-wg-charter.html

@RicardoUsbeck and others participating in Code for Leipzig already expressed interest in JSON-LD #118