|
| 1 | +.. _governance: |
| 2 | + |
| 3 | +TorchMetrics Governance |
| 4 | +####################### |
| 5 | + |
| 6 | +This document describes governance processes we follow in developing TorchMetrics. |
| 7 | + |
| 8 | +Persons of Interest |
| 9 | +******************* |
| 10 | + |
| 11 | +Leads |
| 12 | +----- |
| 13 | +- Nicki Skafte (`skaftenicki <https://github.com/SkafteNicki>`_) |
| 14 | +- Jirka Borovec (`Borda <https://github.com/Borda>`_) |
| 15 | +- Justus Schock (`justusschock <https://github.com/justusschock>`_) |
| 16 | + |
| 17 | + |
| 18 | +Core Maintainers |
| 19 | +---------------- |
| 20 | +- Luca Di Liello (`lucadiliello <https://github.com/lucadiliello>`_) |
| 21 | +- Daniel Stancl (`stancld <https://github.com/stancld>`_) |
| 22 | +- Maxim Grechkin (`maximsch2 <https://github.com/maximsch2>`_) |
| 23 | +- Changsheng Quan (`quancs <https://github.com/quancs>`_) |
| 24 | + |
| 25 | + |
| 26 | +Alumni |
| 27 | +------ |
| 28 | +- Ananya Harsh Jha (`ananyahjha93 <https://github.com/ananyahjha93>`_) |
| 29 | +- Teddy Koker (`teddykoker <https://github.com/teddykoker>`_) |
| 30 | + |
| 31 | + |
| 32 | +Releases |
| 33 | +******** |
| 34 | + |
| 35 | +We release a new minor version (e.g., 0.5.0) every few months and bugfix releases if needed. |
| 36 | +The minor versions contain new features, API changes, deprecations, removals, potential backward-incompatible |
| 37 | +changes and also all previous bugfixes included in any bugfix release. With every release, we publish a changelog |
| 38 | +where we list additions, removals, changed functionality and fixes. |
| 39 | + |
| 40 | +Project Management and Decision Making |
| 41 | +************************************** |
| 42 | + |
| 43 | +The decision what goes into a release is governed by the :ref:`staff contributors and leaders <governance>` of |
| 44 | +Lightning development. Whenever possible, discussion happens publicly on GitHub and includes the whole community. |
| 45 | +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. |
| 46 | + |
| 47 | +Commits to the project are exclusively to be added by pull requests on GitHub and anyone in the community is welcome to review them. |
| 48 | +However, reviews submitted by |
| 49 | +`code owners <https://github.com/PyTorchLightning/metrics/blob/master/.github/CODEOWNERS>`_ |
| 50 | +have higher weight and it is necessary to get the approval of code owners before a pull request can be merged. |
| 51 | +Additional requirements may apply case by case. |
| 52 | + |
| 53 | +API Evolution |
| 54 | +************* |
| 55 | + |
| 56 | +Torchmetrics development is driven by research and best practices in a rapidly developing field of AI and machine |
| 57 | +learning. Change is inevitable and when it happens, the Torchmetric team is committed to minimizing user friction and |
| 58 | +maximizing ease of transition from one version to the next. We take backward compatibility and reproducibility very |
| 59 | +seriously. |
| 60 | + |
| 61 | +For API removal, renaming or other forms of backward-incompatible changes, the procedure is: |
| 62 | + |
| 63 | +#. A deprecation process is initiated at version X, producing warning messages at runtime and in the documentation. |
| 64 | +#. Calls to the deprecated API remain unchanged in their function during the deprecation phase. |
| 65 | +#. One minor versions in the future at version X+1 the breaking change takes effect. |
| 66 | + |
| 67 | +The "X+1" rule is a recommendation and not a strict requirement. Longer deprecation cycles may apply for some cases. |
0 commit comments