` packages. Acceptable?
6. **Large independents** – RTK, TubeTK, WebAssemblyInterface likely stay independent. Others?
Full proposal with module assignments, CMake mechanism details, and implementation phases is in the [tracking issue #6060](https://github.com/InsightSoftwareConsortium/ITK/issues/6060). Please comment there for decisions that need to be recorded; use this thread for broader discussion.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [April 15, 2026, 1:37pm UTC](https://discourse.itk.org/t/reorganize-remotemodules-for-reduced-maintenance-burden/7753/2 "2026-04-15T13:37:43Z")
This enable remote modules to be turned on in Groups? It does not consolidate the numerous repos?
I thought that much of the burden of maintenance was related the number of remote repositories that need to be maintained. I’m not sure this addresses it.
I would find the option to enable module based on the compliance level useful or similar meta-data. For example if a change is made in core ITK then it may be useful to enable remotes of level 4+ which would have a good guarantee that they would work out of the box.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [April 15, 2026, 2:27pm UTC](https://discourse.itk.org/t/reorganize-remotemodules-for-reduced-maintenance-burden/7753/3 "2026-04-15T14:27:59Z")
> It does not consolidate the numerous repos?
It does, though it was not immediately clear to me either.
+1 for having the support level play a in role in module grouping.
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [April 16, 2026, 12:51am UTC](https://discourse.itk.org/t/reorganize-remotemodules-for-reduced-maintenance-burden/7753/4 "2026-04-16T00:51:16Z")
> [@blowekamp](#):
>
> I would find the option to enable module based on the compliance level useful or similar meta-data. For example if a change is made in core ITK then it may be useful to enable remotes of level 4+ which would have a good guarantee that they would work out of the box.
I have a draft proposal to try exactly this out. I think it is the way to go to provide metadata, and guidelines of what level of quality users should expect. That will be much easier to maintain in a single repository.
For every integrated remote module, retain the following “report card” intent and inject the final “Grade Level” as a static cmake variable for selecting quality levels easily.
```auto
#-- # Grading Level Criteria Report
#-- EVALUATION DATE: 2020-03-24
#-- EVALUATORS: [Dženan Zukić]
#--
#-- ## Compliance level 5 star (AKA ITK main modules, or remote modules that could become core modules)
#-- - [] Widespread community dependance
#-- - [] Above 90% code coverage
#-- - [] CI dashboards and testing monitored rigorously
#-- - [X] Key API features are exposed in wrapping interface
#-- - [] All requirements of Levels 4,3,2,1
#--
#-- ## Compliance Level 4 star (Very high-quality code, perhaps small community dependance)
#-- - [X] Meets all ITK code style standards
#-- - [X] No external requirements beyond those needed by ITK proper
#-- - [] Builds and passes tests on all supported platforms within 1 month of each core tagged release
#-- - [] Windows Shared Library Build with Visual Studio
#-- - [] Mac with clang compiller
#-- - [] Linux with gcc compiler
#-- - [] Active developer community dedicated to maintaining code-base
#-- - [] 75% code coverage demonstrated for testing suite
#-- - [X] Continuous integration testing performed
#-- - [X] All requirements of Levels 3,2,1
#--
#-- ## Compliance Level 3 star (Quality beta code)
#-- - [X] API | executable interface is considered mostly stable and feature complete
#-- - [X] 10% C0-code coverage demonstrated for testing suite
#-- - [X] Some tests exist and pass on at least some platform
#-- - [X] All requirements of Levels 2,1
#--
#-- ## Compliance Level 2 star (Alpha code feature API development or niche community/execution environment dependance )
#-- - [X] Compiles for at least 1 niche set of execution envirionments, and perhaps others
#-- (may depend on specific external tools like a java environment, or specific external libraries to work )
#-- - [X] All requirements of Levels 1
#--
#-- ## Compliance Level 1 star (Pre-alpha features under development and code of unknown quality)
#-- - [X] Code complies on at least 1 platform
#--
#-- ## Compliance Level 0 star ( Code/Feature of known poor-quality or deprecated status )
#-- - [] Code reviewed and explicitly identified as not recommended for use
#--
#-- ### Please document here any justification for the criteria above
# Code style enforced by clang-format on 2020-02-19, and clang-tidy modernizations completed
```