Split Data Package spec into its own repo

[rufuspollock]

See #20 for discussion of why this would be useful. Main benefit would be having issues for data package in its own repo (and also to start having branches etc)

@paulfitz what do you think? Is this worth it?

[paulfitz]

@rgrp I find the benefit of having individual versioning/tagging to be compelling, both as an author of a spec, and someone who'd like to cite other specs.

I could poke at the dataprotocols.org side of this if you like (using submodules or redirects like we talked about). I've some deadlines at the moment, but could chip in later next week.

[rufuspollock]

@paulfitz good - let's move it out.

All that should be needed here it so renamed this repo to dataprotocols.github.com and then to move datapackage spec to a repo named e.g. datapackage :-) (if we got fancy we might want to submodule the _layouts stuff so we don't duplicate ...). This isn't urgent so if you were up for looking at this next week that would be great!

[paulfitz]

Oh I think I see your idea, I had something more convoluted in mind.

Doing a quick experiment here http://paulfitz.github.io/datapackage/ (repo https://github.com/paulfitz/datapackage), I realize that we have three bits of structure that all repos might want: _layouts, _includes, and css. I guess it'd be ok to just use the css with an absolute path. Jekyll has no flexibility that I can see in where _includes is (must be top-level, must be so named, no subdirectories). It does have flexibility in where _layouts is. So, in order to avoid needing two submodules how do you feel about the following hack:

• Move contents of dataprotocols/_includes into a separate repo
• Move contents of _layouts inside that repo
• Include that repo as _includes everywhere
• Add layouts: ./_includes/_layouts in _config.yml everywhere

I'm not totally sure what the story will be with updating pages when the style changes, not sure if github is smart enough to update everything effected, could be clunky.

Just to mention an alternative: suck datapackage in as a submodule of the existing dataprotocols site. It could have its own layout (or not) for hacking on it locally, but rendering would be as currently done.

[rufuspollock]

@paulfitz quick thoughts

• do we need _includes (do we reuse - if not we could inline stuff into relevant templates ...)
• if we hardcode css link (which is fine) thhen we are left just with _layouts which we could submodule in via a separate repo (as you describe)

It will be slightly clunky if we change the template a lot but otherwise should be pretty easy ...

In terms of the inverse approach: that's kind of nice - one pain would be that rendering data-package itself wouldn't work too well but the more i think about it the more i like this ;-)

So: perhaps we should explore the latter option (i.e. such data-package in as a submodule to main site) and see how that goes ...

[paulfitz]

@rgrp ok, I tried the latter option, spinning dataprotocols/data-packages off to https://github.com/dataprotocols/data-packages and including it again as a submodule. Everything appears to still be working :-)

[rufuspollock]

@paulfitz looks very good. Shall we move from experimental to "stable" and close this issue. Next step I guess would be gradually migrating issues across.

[paulfitz]

@rgrp Yes, closing.