Meeting 2026 09 21 - wmo-im/tt-wismd GitHub Wiki

Date/Time

Monday 21 September 2026 12h - 13h30 UTC

Location

MS Teams

Attendees

Team

Name Affiliation/Country GitHub handle Attendance
Tom KRALIDIS (Chair) Canada @tomkralidis X
Guillaume AUBERT EUMETSAT @gaubert X
Takumu EGAWA (observing member) Japan
Lara FERRIGHI Norway @ferrighi X
Sylvain GRELLET France @sgrellet
Xinqiang HAN China @Amienshxq X
Vera KORBULAKOVA Russian Federation @VeraKorbulakova X
Ian MCDONALD EUMETSAT @McDonald-Ian
Steve OLSON USA @solson-nws X
Ján OSUSKÝ HMEI @josusky X
David PODEUR France @davidpodeur
Julia SIELAND Germany @jsieland X
Yutaro TONOOKA Japan YutaroJMA
Yusuke NAKAGAKI Japan X
Anna MILAN WMO Secretariat @amilan17 X
Washington OTIENO WMO Secretariat

Agenda

Notes

Previous meeting actions

  • Tom's KPI title check and PyWCMP actions are done.
  • Lara's proposed KPI for metadata concepts (topic category richness, resolvable URLs) had not been rushed for INFCOM-4 and was picked up later in this meeting under issue #305.
  • The action to review the WCMP2 KPI Annex ahead of the end-of-June deadline was overcome by events.

Secretariat updates (Anna)

  • A set of WIS2 Notification Message changes for INFCOM-4 is in an open PR: reviewed by the SC-IMT chair, by Secretariat colleagues, and by the INFCOM President, and is now going through INFCOM's own approval process ahead of publication. These changes cannot be merged to main until they clear INFCOM and then Congress (expected early/spring 2027).
  • Because of this INFCOM-4 process, there will not be a second 2026 fast-track amendment cycle for the specifications; further amendments would target Fast Track 2027-1.
  • A separate, minor fast-track procedure change is being proposed: reducing the national focal point review window for fast-track amendments from two months to one month (also requires Congress approval), to speed up turnaround and potentially allow more fast-tracks per year.
  • A new appendix on WIS2 monitoring events has been added to the WIS2 Manual, alongside the notification message changes.
  • The WCMP2 KPIs went straight into main as new work (not part of the INFCOM-4 PR) but will be presented in the WIS2 Guide.
  • The WMO Manual is now managed on GitHub in AsciiDoc (previously a Word document).
  • Anna to share the relevant manual/guide PR links in the team chat.

WCMP2 — KPI dashboard way forward

  • Idea (following the June metadata-analysis demos): build a metadata-quality dashboard on top of the WIS2 metric hierarchy (e.g. Prometheus/Grafana or an ELK stack), going one level deeper than the existing Global Monitors dashboards, which currently only expose an overall KPI score per center.
  • The existing Global Monitors metadata dashboards are operational (run by CMA and Morocco) but access-controlled — username/password protected, visible mainly to WIS2 Operations and WIS2 Implementation & Transition experts.
  • Discussion focused on identifying users/purpose before building anything: data providers/centers (self-assessment of their own metadata quality), JISCs (quality oversight across their area of responsibility), Secretariat (overall/quarterly reporting), and other task teams. The framing agreed on is quality and continuous improvement, not compliance.
  • A "wall of shame" concern was raised (public, unauthenticated visibility of low scores) — the sense of the room favoured keeping it access-controlled, consistent with the existing dashboards, though Lara noted it could still be motivating if scoped and communicated carefully.
  • Two implementation paths were discussed: (1) GDCs take on responsibility for emitting per-KPI metrics that feed into the existing global-monitor infrastructure, or (2) build a separate dashboard/hierarchy (e.g. via the WIS2 GDC reference implementation). Option 1 was seen as the shorter path since it reuses existing infrastructure.
  • Agreed way forward: Tom will raise per-KPI metric emission by GDCs as a discussion item at the next W2IT meeting to get feedback from GDC operators. Ján (W2IT member) was supportive and noted metadata volumes are low enough that this shouldn't be an infrastructure concern.

WCMP2 — themes/concepts proposal (issue #305)

  • Lara's proposal: award a KPI when a record supplies theme/concept entries beyond the single mandatory Earth-system-discipline topic-hierarchy concept — particularly when those extra concepts come from a defined/resolvable schema (e.g. another WMO code list, or an external vocabulary such as INSPIRE), and/or when a fully resolvable URL is given rather than just an ID + schema (which, as with BUFR, doesn't always reconstruct to a working URL).
  • It's unclear how much this is already used in practice — WIS2Box currently only implements the mandatory concept, so real-world adoption of additional themes/concepts is likely low. The group agreed the KPI is still valuable even with initially low scores, since richer metadata aids interoperability and discovery, and could motivate implementations (including WIS2Box) to add support.
  • Agreed to move forward with adding this as a KPI, targeting Fast Track 2027-1 (per Anna, expected approval/implementation around May/June 2027, with manuals and guides republished shortly after Congress).
  • Action: Lara to draft a PR against the KPI repo (starting from an example AsciiDoc entry) to add this KPI.

WCMP2 — codelists: "retired" status (issue #34)

  • Jeremy's issue asks to add a "retired" token to the operational-status code list, per the cookbook recipe. Clarification: WCMP2's properties.status is not currently bound to any code list — it's a free concept (mandatory ID, optional title/URL) left deliberately open in the spec, in part because "status" turned out to be an overloaded term.
  • Extended discussion distinguished two things often conflated under "status": (1) a data set's life-cycle/production status (e.g. ongoing, obsolete, retired) and (2) its operational status (e.g. experimental, pre-operational, operational) — Met Norway's code lists already model these separately.
  • Because status is optional, a wording/definition clarification is not a breaking JSON-schema change, though renaming the element outright would be more complex to push through WMO's technical-regulation process. A quick catalog check suggests very few, if any, records currently populate status at all, which lowers the risk of any change.
  • A tentative direction discussed: keep status as-is but clarify (via a schema/spec text update, not a technical-regulation change) that it represents lifecycle status, and separately consider adding a new operational-status element. If added, the group debated whether operational status should be constrained to a code list (useful if it needs to be filterable/queryable, e.g. to exclude retired or experimental data) or left free-form like status is today.
  • No firm decision was reached before time ran out; reusing themes/concepts to carry a typed status entry (Ján's suggestion) was floated as one lightweight alternative. Way forward: continue on issue #34 and wait for Jeremy's response before converging on an approach.

OTHER open issues

Not discussed — carried to next meeting.

Roundtable

  • Guillaume raised a case where a GDC rejected metadata that was valid against the latest WCMP2 version, and asked whether there's a documented process for rolling out breaking metadata versions / supporting dual versions across GDCs. Tom noted this connects to an existing WIS2-Ops sweep of records ingested before 1 January 2025, which will become invalid under current validation. Guillaume will open an issue and Tom will cross-link the related work.

Actions

  • Tom: add individual KPI analysis option to pywiscat
  • Anna: get team access to the Global Monitors to review their approach
  • Tom: raise per-KPI metric emission by GDCs (WCMP2 dashboard way forward) as a discussion item at the next W2IT meeting
  • Lara: draft a PR and example for the themes/concepts KPI, targeting fast-track 2027-1 for issue #305
  • Guillaume: open an issue on GDC support for multiple metadata versions / transition periods for breaking metadata changes
  • All: await Jeremy's response on issue #34 (retired/operational status codelist) before agreeing a way forward

Next meeting

YYYY-MM-DD — approx. one month out; date to be circulated by Anna.