Quality of Governance Indicators

[christophergandrud]

@briatte Thanks for suggesting placing your QoG work together in one place with psData.

First attribution: This would be a really big contribution, so I'ld be more than happy to add you as a contributor to the repository and make you an author on the package overall. Just let me know.

Things to discuss/work on:

Unified syntax: I think to make the package really user friendly we should work on unifying the syntax across the commands that gather the different data sets. I've worked out kind of a start, but I'm not particularly wedded to anything. We should discuss this further.

Unified data object class and data handling methods: I really like what you've done with adding additional capabilities to lag/lead/graph the data. It would be great to apply this across the other sources.

Thoughts on moving forward:

If you want to merge psData and your work together I think:

1. I should first give you contributor status on the psData repo.
2. We start a qogDev branch to psData which you can patch over the code into.
3. We should start co-writing a JSS style package description paper while we unify the syntax and data handling methods across the commands. I think writing a paper while doing this will (a) help us clearly delineate the package structure and usage, (b) provide a guide to other possible contributors (who may also become co-authors), and (c) satisfy our need to appease the academic gods who are hungry for papers.

Quick question:

• Does the current version of qogdata pass CRAN check?

Just let me know what you think about this plan as a way forward.

[antagomir]

@muuankarski is also working on QoG data under rOpenGov: http://markuskainu.fi/rqog/ so I am linking you all. Perhaps the QoG could even make its own package based on your joint work? In our experience it is quite useful to split the code in multiple smaller and compact packages.

[muuankarski]

@antagomir pointed me to this debate. Very interesting. As said I have worked a bit on that data, too.

• package: https://github.com/muuankarski/rqog
• some examples: http://muuankarski.github.io/rqog/vignettes/rqog_tutorial.html

My approach is a maximun simplicity as emphasized by @antagomir in this issue meaning that there is only one function read_qog that downloads the data into defined local folder and reads it in R. If the local file exists the function only reads the data.

It follows the logic we have had preliminary discussions within rOpenGov, that is, to make the packages to serve reproducibility of the workflow, but also to keep them simple for (sustainable) maintenance. My plan for the deveploment has been to work on the cache next week and publish it in rOpenGov soon.

However, I would welcome any insight of the data and of it's use, and @briatte, you seem to be well into it. Any ideas on combining our efforts?

[christophergandrud]

This is a really interesting issue. Maybe there is a way to get a 'best of both worlds'. I'm thinking something like creating a common core syntax and set of capabilities that could be implemented across multiple packages that gather country-year data. This way it would be easy for users to download data, clean it, and easily merge it into one data set, without having to learn different syntax and capabilities for a number of different packages.

Does this make sense?

[antagomir]

Harmonization would be extraordinarily useful. Coordinating this between different package authors might be challenging but with individual authors or small groups it may still work and definitely the way to go in my view.

In any case, I strongly advocate small and compact packages following the *nix principle of 'do one thing and do it well'. Higher-level packages can be built on top of such components.

[christophergandrud]

I like it. I'm going to close this issue and start another one with thoughts on how to move forward for people who are interested.

[briatte]

The qogdata package was never submitted to CRAN because I was waiting for the psData package to happen and find coauthors to have these conversations — so I'm more than willing to join the crew.

@muuankarski — some of our functions are virtually identical from a user perspective. The only thing I did more was to go one more step towards Stata-like simplicity and add one-liners to emulate xt commands for panel data.

Harmonization would be extraordinarily useful.

That's what I aimed at, because all my students ask for help when it comes to merging (joining) panel data (tables). That's why I'd like to +1 the JSS paper idea from @christophergandrud: I'm pretty sure there's an audience for "easily manipulate CSTS data with R".

Let's go for the dev branch, I'll start committing this weekend!

Unified data object class and data handling methods: I really like what you've done with adding additional capabilities to lag/lead/graph the data.

If I remember correctly, one of the panel shift functions comes from one of your blog posts. @zmjones also coded several panel data functions. His input would be valuable on the 'unified methods' question.