Summary of devstats work from summit 2025

[nabobalis]

I am using this issue to track the overall discussion and conclusions we came to during the summit regarding devstats.

So Jake and I hacked more on the data, fixing a few bugs, adding more data from issues and PRs which will enable us to close some of the open issues.

However, discussing devstats with several members over the summit, what became clear to me is that we have lots of options to choose from and we need to form a more coherent vision of what we need devstats to be.

From the potential improvements suggested, I think the interactive frontend brings up the question about the audience and what we want them to be able to achieve.

For example, how interactive does devstats need to be? This will decide which technologies we want to use.
Do we want to have better graphs which allow more filtering and more interactive metadata like links to issues or PRs based on the static data we pull from GitHub. Or would we want to go further and allow someone to make new queries from GitHub and plot that data? I don't have a good sense of if the last one is just too generic of an idea.

These are things we can work on async to help work out where we want to go:

• Ask those who have to fill in grants, what kind of questions do they need answered that we can add to the devstats website.
• Ask those who are interested in the health of a project what information they need. Also has a security angle.
• Work out what statistics is useful for answering, is this a load-bearing package and is it under-maintained.
• See if we can replace the existing github query tooling with https://github.com/executablebooks/github-activity
• If we can, should scientific-python control the repo? We can help maintain it at the very least regardless of where it lives.
• See if we can leverage some of the figures/ideas from https://chrisholdgraf.com/jupyter-activity-snapshot/jupyter.html
• Is there a set of static figures we could generate for other projects to embed in to their documentation?

A broader question: Do we want to host the tooling and then let projects set up their own "devstats" so they can pick what information is useful for their own project?