updating devstats.scientific-python.org

[nabobalis]

(Sorry if I am not doing this correctly)

I wanted to see if anyone wants to work on the devstats website?

I see there are few older PRs and some issues open but my immediate thought was to make the devstats "live" by adding a weekly/monthly cron that will update the statistics.

I also am interested in the scaping at the org level and adding support for that. I would not suggest adding this to the website but for example sunpy, a lot of development now happens off the main repository and I want to see the stats of the organization and not just the main repository.

[thomasjpfan]

If we agree on the current devstat site's audience, then I'll be interested in having a "live" devstats site.

Context: In scikit-learn, I created two sites for triaging issues and pull requests that gets updated daily:

• sklearn-repo-status site, which gives shows a thread of how things are going
• sklearn-pr-tracker, a tool to help find PRs that have small diffs, which usually takes less time to review (not always the case)

For me, I wanted a devstats site where the audience are maintainers or contributors and gives actionable insights. The current https://devstats.scientific-python.org site, provides a summary of historical trends and overall health, but it does not give me anything actionable.

In this context, I have two questions:

• If devstats.scientific-python.org was updated monthly, would you find it useful?
• What kind of devstats are useful to you?

[rossbar]

If we agree on the current devstat site's audience, then I'll be interested in having a "live" devstats site.

Agreed @thomasjpfan - for a bit of context, a lot of the original impetus for the devstats site came from perspective of "report generation", e.g. automating grant deliverables etc. Personally, I'd be more interested in devstats from the perspective you describe - interactive exploration/filtering of timely information for extraction of actionable info. FWIW I think the biggest limitation on devstats has always been answering the question: "what info is most useful and to whom".

[nabobalis]

Sorry for the late reply!

Context: In scikit-learn, I created two sites for triaging issues and pull requests that gets updated daily:

• sklearn-repo-status site, which gives shows a thread of how things are going
• sklearn-pr-tracker, a tool to help find PRs that have small diffs, which usually takes less time to review (not always the case)

These are pretty nice, I would be interested in rolling them for sunpy!

For me, I wanted a devstats site where the audience are maintainers or contributors and gives actionable insights. The current devstats.scientific-python.org site, provides a summary of historical trends and overall health, but it does not give me anything actionable.

I think this brings up a very interesting divergence.
I actually would personally be interested in both angles.

Understanding the historical performance the sunpy core library, how it might compare to newer projects under our project while not actionable directly could help us decide if smaller projects are growing how we expect and maybe if it's time to shutter them. This is why I care about the organization wide addition.

But on the flip side, as I am a maintainer/contributor, actionable insights allow us to triage issues or PRs, get them reviewed etc are useful to help us manage any project.

By saying all of this, this doesn't seem the kind data/project that would be hosted by scientific python. For me, it would not make much sense for scientific python to host such specific data for each project.

If we could expand the generation code to make both sets of information (report generation and actionanle statistics), even if scientific python doesn't host the data/website, if the code was maintained at this level, that would be nice?

[bsipocz]

While I would love to use the interactive exploration of devstats for actionable items, in practice I found it super useful already for generating snapshot for proposal writing, talks, etc.

So for the snapshot use case, it would be useful to have an updated version on with ~monthly cron.