TorchMetrics Governance

This document describes governance processes we follow in developing TorchMetrics.

Persons of Interest

Leads

• Nicki Skafte (skaftenicki)

• Jirka Borovec (Borda)

• Justus Schock (justusschock)

Core Maintainers

• Daniel Stancl (stancld)

• Luca Di Liello (lucadiliello)

• Changsheng Quan (quancs)

• Shion Matsumoto (matsumotosan)

Alumni

• Ananya Harsh Jha (ananyahjha93)

• Teddy Koker (teddykoker)

• Maxim Grechkin (maximsch2)

Releases

We release a new minor version (e.g., 0.5.0) every few months and bugfix releases if needed. The minor versions contain new features, API changes, deprecations, removals, potential backward-incompatible changes and also all previous bugfixes included in any bugfix release. With every release, we publish a changelog where we list additions, removals, changed functionality and fixes.

Project Management and Decision Making

The decision what goes into a release is governed by the staff contributors and leaders of TorchMetrics development. Whenever possible, discussion happens publicly on GitHub and includes the whole community. When a consensus is reached, staff and core contributors assign milestones and labels to the issue and/or pull request and start tracking the development. It is possible that priorities change over time.

Commits to the project are exclusively to be added by pull requests on GitHub and anyone in the community is welcome to review them. However, reviews submitted by code owners have higher weight and it is necessary to get the approval of code owners before a pull request can be merged. Additional requirements may apply case by case.

API Evolution

TorchMetrics development is driven by research and best practices in a rapidly developing field of AI and machine learning. Change is inevitable and when it happens, the Torchmetric team is committed to minimizing user friction and maximizing ease of transition from one version to the next. We take backward compatibility and reproducibility very seriously.

For API removal, renaming or other forms of backward-incompatible changes, the procedure is:

1. A deprecation process is initiated at version X, producing warning messages at runtime and in the documentation.

2. Calls to the deprecated API remain unchanged in their function during the deprecation phase.

3. One minor versions in the future at version X+1 the breaking change takes effect.

The “X+1” rule is a recommendation and not a strict requirement. Longer deprecation cycles may apply for some cases.