Improve statistics view

[loleg]

Compared to, for example, the analytics view of a Slack workspace, the graph of activities in our admin dashboard is still sorely lacking. Let's improve this! In particular, discussing with hackathon organizers it sounds like the interesting statistic would be to describe how much time / performance actually went into the event. An overview of the teams with their "working rhythms", kind of a Gantt chart of when they were posting, would be cool. Some infographic-ready stats, like number of people, posts, total hours, etc., would be very useful as after-event analysis. Perhaps this could be generated as part of the Report feature.

[loleg]

Something I often come back to in the context of gathering data at hackathons, are the thoughts of visionary open data activist David Eaves on the topic of community management. From a 2012 interview:

[David] sees a significant impact (and even greater potential impact) from tools that communities don't specifically use for their impact on their social sides--tools like Github and the metrics tools that Mozilla has embraced. "One of the things that strikes me as so interesting is that there's an enormous amount of data about how communities work, but it's locked up in interfaces like Bugzilla," he said. These tools introduce some art into the science by giving us a lot of really useful information about the interactions in a community.

What if you were paying a lot more attention to not just the hard data, like what's been submitted, but who has been doing it? Maybe you'll notice a person who has usually been a regular contributor but suddenly hasn't submitted a patch in two months. That gives you an opportunity to reach out and find out what happened. You're likely to find either that something intervened--life changes, job changes--something that has just changed the person's ability to participate. or maybe you'll find that the person intentionally left your project. That's the opportunity to find out why and to do something about it.

You can also use this data to set expectations, which in turn reduces community frustration. Imagine that when a contributor makes a submission, it came with a graph showing how long on average it takes for code to be reviewed. With expectations known, you'll have a lot less ire from a simple misconception about how the community usually operates.

"The best code will not always win. Community management is a core competency to making open source effective," Eaves concluded.

(opensource.com)