Or is aggregating at the project level and individual wiki level enough?
Topic on Talk:Wikistats 2.0 Design Project/RequestforFeedback/Round1/Component wiki selector
I am not sure, I thought activity in all wikis together was a metric WMF was actively using.
We use it sometimes, sure, but WMF is not the audience we're interested in reaching with Wikistats. So we didn't want to assume all-wiki aggregates are also useful to editors and community organizers and other parts of the community.
WMF is not the audience we're interested in reaching with Wikistats.
This concerns me a bit—Wikistats is used constantly within the WMF and (just on a personal level) saves me a lot of time because for common queries I can direct staff members there instead of doing a custom query and graph for them, or declining their request entirely.
I feel like we should strive to build something that's useful to both WMF staff and volunteers, particularly when their needs (like gaining a non-anecdotal understanding of our projects) are so similar.
On the specific topic here, I think people from all the audiences (including WMF staff, volunteers, and the press) are interested in seeing aggregate numbers, particularly for things like pageviews and active editors. I definitely would say that aggregating by project or wiki is not enough.
I should have said (and I did in other places, sorry for the omission here) that WMF is not the _primary_ audience we're interested in reaching. We'll definitely make sure Wikistats 2.0 is useful for everyone, including WMF staff. But Wikistats has a more important role to play: making up for the community's lack of dedicated analysts. Our co-workers are lucky enough to have you and a bunch of other great analysts. I'm not just saying that to be nice, it's a huge luxury. And Wikistats, which predates WMF, has always been the community's analyst. We think that's an important role, and that's why we made it our primary focus.
Well, I appreciate the kind words. But I think you are overstating the ability of me and the other analysts to satisfy the demand for data within the WMF. I am one analyst in a team of 35, and I don't have enough time to satisfy most of their requests, let alone all the requests I get from other departments, volunteers, and C-levels. Better data for staff is not just nice to have someday, it's a major strategic issue, even if Wikistats isn't the right place to solve it.
However, that's a side point. What I'm really interested in is what exactly this principle (the needs of project volunteers taking primacy over the needs of WMF staff) implies to you, so I can figure out if I agree with it or not :) I can't think of many cases where their Wikistats-relevant needs actually diverge. For example, it's not the case that only staff want Wikimedia-wide aggregate numbers: there are many Metapedians who think deeply about movement-wide issues and want relevant data to inform that. Nor is it the case that only staff want, say, product-level data about how often the visual editor and the wikitext editor are used (not that this should necessarily be in Wikistats). Many volunteers are passionate about software development questions like those.
If I understand this, I'll better understand what your vision for Wikistats is, and how it will fit in with the rest of the data tools in the movement. Sorry for the long post :)
I appreciate the one in 35 feeling, believe me, and I'm sorry, I didn't mean to minimize that.
To your point, I agree, I don't think use cases of inside-WMF and outside-WMF diverge very much. We tend to build infrastructure that can handle general problems anyway, so even if we give a nicer UI treatment to specific use cases of our communities, we would still make that data available on Hive + Druid. So we're going to support our WMF analyst staff almost by definition of how we work.
My opinion isn't law here by any stretch, but here's an example of what I personally mean. Say you wanted a more complicated way to visualize some data, like the sunburst on https://edit-analysis.wmflabs.org/compare/. And we asked the community and they made the point that including it would complicate the interface and make Wikistats less useful. Then I think we'd have an "advanced" version of Wikistats where we would sort of segregate visualizations like that. And if people wanted to pull them into the more mainstream experience later, that's cool too. So, I'm thinking just that communities should have editorial control over how Wikistats feels and what they can do with it.
Hm, I can't think of any more practical example, that one was probably wrong (they'd probably like the sunburst). But hopefully I conveyed the idea. I essentially think this will never be a problem, but I feel that it's important to defer to the communities if it ever comes up.