MetOffice / MetOffice/SimSys_Scripts

Expanding project reporting functionality

Open
#204 1 comment 0 reactions 1 assignee View on GitHub

@cameronbateman-mo is already working on this.

Since Mar 6, 2026.

Dominant language
Python
Stars
9
Forks
19
Avg merge
5d 48m
Merged PRs (30d)
4

Description

Once finish_milestone.py has been run all the PRs are archived from the project. In order to easily gather statistics about a release its therefore good to gather that information as part of the script. There is currently a short reporting function that prints the number of pull requests by repo to the terminal while running which can be expanded and modified.

Questions:
* What is the best format for storing these statistics? [A spreadsheet was put together for 2026.03.1 to manually record the data before the archiving was done. Follow this principle?](https://metoffice.sharepoint.com/:x:/r/sites/scienceitteam/Shared%20Documents/SSD%20Team/Release%20Notes/2026.03.1%20Stats.xlsx?d=wac715e53533c4b0ab07a6cb55b0009fc&csf=1&web=1&e=i4wvSr)
* Is this functionality only needed after the release (and can therefore be part of finish_milestone.py), or would it be nice to run mid-release to gather information (e.g. for a presentation or meeting) and therefore should be a standalone script that can be called by finish_milestone.py?
* What details need to be gathered? The 2026.03.1 caught assignees, reviewers, repos and labels. Is this all?

Breakdown:
- [ ] In finish_milestone.py modify the report to store the current repository data to a suitable file
- [ ] Update review_project.py so that all details required are extracted from the raw json
- [ ] Add functions to aggregate those statistics nicely (there are routines for counting items but they are limited at the moment)
- [ ] Expand report funtions to cover the extra stats
- [ ] Move report functionality to its own file if wanted
- [ ] Investigate no error being thrown when permissions for archiving are not set correctly for the user of the script.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.