[datacatalogs] Proposal: migrating datacatalogs.org to a new simpler setup

[James McKinney]

The trouble with using Google Spreadsheets as the master data source is that its versioning is absolutely terrible.

The current datacatalogs.org has good versioning, as would the CSV in git proposal.

For me, the two criteria that need to be balanced are: easy contribution and good edit histories. The criteria are easily met when editing happens inside the app, because you can control everything. When you move the editing out of the app into git or Google Docs you lose one or the other. I suppose if GitHub supported spreadsheets editing then this wouldn’t be a problem. A YAML file would be somewhat easier to edit in git than a CSV file, but it would be more prone to corruption if a maintainer makes a bad edit, which can break the entire site.

James


On May 9, 2014, at 12:29 PM, Rufus Pollock <rufus.pollock at okfn.org> wrote:

> On 9 May 2014 17:18, James McKinney <james at opennorth.ca> wrote:
> I use datacatalogs.org to maintain the list of Canadian data catalogs.
> 
> I don’t see what file I would edit during a pull request. It looks like everything comes from Google Docs. Is the "CSV in git" part not done? Are reviewers expected to transform Google Form submissions into pull requests? Will the data sources (CSV or Google Docs) be
> 
> No this part was about a proposal :-)
> 
> My feeling was google form might be easiest for non-techies and then an editor/reviewer merges that either into primary google spreadsheet  or into a csv in git.
>  
> synced with datacatalogs.org before the switch?
> 
> Yes.
>  
> I see the new process as making it more difficult for non-tech-savvy maintainers to maintain their catalogs - they need to rely on git-savvy people. In any case, will the current catalog maintainers have commit access so that we don’t need to wait on OK staff to merge
> 
> That's why Google Spreadsheet option might be better.
>  
> pull requests? I think the CSV should be in a separate repository.
> 
> To be clear whatever DB is it will be open to current catalog maintainers whomever they are (nothing  to do with OK staff :-) - other than they being maintainers)
>  
> I’ve created new issues, and issues #8, #10, #16 should be the priority before any switch.
> 
> thanks and good suggestions.
> 
> Rufus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/data-catalogs/attachments/20140509/a1f1335d/attachment-0003.html>