What problems would this solve? =============================== Certain metrics we would like to track currently require a database export and complicated SQL, and therefore we don't produce them often or use them to inform our activities. Who would use this? =================== Primarily product team members. Potentially any interested visitor. What would users see? ===================== Users authorized to see the metrics would see... * Metrics about contribution, such as the number of contributors who made X revisions for the last Y months (e.g. core contributors) * Metrics about user accounts (how many, how many are active contributors, what is the rate of change) * Other metrics that we track now or later that come from queries against the wiki database * Potentially, a small number of controls to change metrics display ("in the last [week|month|3months|year]") What would users do? What would happen as a result? =================================================== Product teams would have more information to inform decisions about features and identify opportunities. Other stakeholders would have more visibility into the wiki's vital stats. Is there anything else we should know? ======================================  "authorized" could be "everyone" or "admins" or something in between. TBD.
Do we want to start from scratch or integrate with existing products like Bitergia or Baloo? I don't think this is our core business and specialists will likely be able to do it better (and more). That would lower dev work to integrate with these rather than to rewrite them. Bitergia is able to measure activities of wikis, mailing-list, forums and aggregate the data. Baloo is able to track a user activity through projects and could help us measure the mobility of our contributors. It will still be a significant amount of work, even without building the system itself.
I think we need to dig into the technical challenges implied by bug 973612 (python version?) before we can push this forward. Could we do that in ~5 days worth of hunting?
Yes, in ~5 days we could: 1. See if we have better Google Analytics python libraries options now that we're on python 2.7 with kuma codebase. 2. Look at pulling the GA wiki visit data into a Google Spreadsheet first, and then importing it from there into our database. Essentially using Google Spreadsheets as our service/library for accessing GA data.
(In reply to Luke Crouch [:groovecoder] from comment #3) > 1. See if we have better Google Analytics python libraries options now that > we're on python 2.7 with kuma codebase. If we use python 2.7, I was able to connect and get data using this one at Hackonmdn https://github.com/googleanalytics/google-analytics-super-proxy