Post by Dario TaraborelliI was under the impression that this data was already being stored
somewhere in temporary tables by Wikimetrics when generating project-level
reports
The data is not being stored anywhere at this time, we just query a table
for users that match a criteria.
Post by Dario Taraborellithis is quite similar to one of the earliest feature requests that we had
for UserMetrics (the predecessor of Wikimetrics) under the notion of
Post by Dario Taraborelli1) take the non-aggregate output of a report (say all registered users or
new active editors from *foowiki *in a given time period)
Post by Dario Taraborelli2) save the output as a cohort
3) re-run that cohort through a different metric
I see. At this time in wikimetrics we have no way to store & reuse
intermediate results of metrics in other metrics. Which, if you notice, is
a performance concern as we recompute stuff. We have talked about doing
this in the past (we called it chaining metrics) and we have some backlog
items to this extent. You can talk to kevin about this use case (which is
slightly different than the original one you described) and he can add it
to the backlog.
On Thu, Oct 2, 2014 at 5:43 PM, Dario Taraborelli <
Post by Dario TaraborelliNuria,
⢠I was under the impression that this data was already being stored
somewhere in temporary tables by Wikimetrics when generating project-level
reports
⢠this is quite similar to one of the earliest feature requests that we
had for UserMetrics (the predecessor of Wikimetrics) under the notion of
1) take the non-aggregate output of a report (say all registered users or
new active editors from *foowiki *in a given time period)
2) save the output as a cohort
3) re-run that cohort through a different metric
Using Quarry still relies on the end userâs ability to understand how to
turn a research question into a query. Having a curated query library is a
good step in that direction, but that still requires some basic knowledge
of SQL.
D
There are no technical blockers to be able to generate that data. Now,
product wise it does not seem like a fit as wikimetrics' purpose is to
produce data and run metrics. All wikimetrics computations are pre-canned.
It seems to me the use cases you passed along are better fitted by a tool
being able to freely query the db like quarry.
Thanks,
Nuria
On Thu, Oct 2, 2014 at 4:00 PM, Dario Taraborelli <
Post by Dario TaraborelliAbbey asked a question during todayâs research group that I wanted to
relay to the wikimetrics devs.
Would it be possible to allow people to use Wikimetricsâ project-level
reports to *generate *cohorts, in other words, obtain lists of user_ids
⢠registered users on a given date or period
⢠newly active editors on a given date
⢠unique editors on a given date or period
UX research as well as LCA would die to have such a functionality (the
fallback is to do this via Quarry or post a request to Research & Data or
someone in Grantmaking).
Dario
_______________________________________________
Wikimetrics mailing list
Wikimetrics at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimetrics
_______________________________________________
Wikimetrics mailing list
Wikimetrics at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimetrics
_______________________________________________
Wikimetrics mailing list
Wikimetrics at lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimetrics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/wikimetrics/attachments/20141002/7fb4b87c/attachment.html>