Add MAINTAINERS_GUIDELINES.md

[jimthompson5802]

Description

Adds MAINTAINERS_GUIDELINES.md to the repos root directory.

Closes Issue #2979. NOTE: the document name (MAINTAINERS_GUIDELINES.md) was selected because the original name (MAINTAINERS.md) is used as the maintainers roster by FINOS.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🎨 Code style/formatting changes
• ♻️ Refactoring (no functional changes)
• ⚡ Performance improvements
• ✅ Test additions or updates
• 🔧 Chore (maintenance, dependencies, CI, etc.)

Affected Components

• CLI (cli/)
• Schema (calm/)
• CALM AI (calm-ai/)
• CALM Hub (calm-hub/)
• CALM Hub UI (calm-hub-ui/)
• CALM Server (calm-server/)
• CALM Widgets (calm-widgets/)
• Documentation (docs/)
• Shared (shared/)
• VS Code Extension (calm-plugins/vscode/)
• Dependencies
• CI/CD

Commit Message Format ✅

Complied with format

Testing

Manual review of the update

• I have tested my changes locally
• I have added/updated unit tests
• All existing tests pass

Checklist

• My commits follow the conventional commit format
• I have updated documentation if necessary
• I have added tests for my changes (if applicable)
• My changes follow the project's coding standards

[jimthompson5802]

@markscott-ms @rocketstack-matt @LeighFinegold This is my proposal for the MAINTAINES_GUIDELINES.md.

[LeighFinegold]

Thanks for putting this together @jimthompson5802. A repo-specific maintainer guide is a genuinely useful addition, and I like that it points back to the governance docs rather than restating them.

On roles more broadly, it could also help to clarify how we handle cross-cutting concerns such as dependency and library upgrades, CI, and security. The guide points at CODEOWNERS for repo-wide files, but it is not clear whether these are a shared responsibility across all maintainers or something specific maintainers own and drive. Being explicit here would help these areas not fall between subproject boundaries as we grow.

Separately, and not blocking this PR: I think we should take a pass over our issue and PR templates to check they still make sense. As was commented on by a few in last meeting office hours, we are increasingly seeing AI-assisted issues and PRs, and because the tools tend to fill in every template section exhaustively, the templates themselves can end up driving very verbose, boilerplate-heavy submissions. I have added an agenda item in next week's office hours (#2990, Thu 20 Aug).

[markscott-ms]

One point raised in the Office Hours was that significant features should be discussed and agreed by maintainers from at least 2 organizations

[jimthompson5802]

@markscott-ms incorprated guideline for

One point raised in the Office Hours was that significant features should be discussed and agreed by maintainers from at least 2 organizations

[eddie-knight]

This looks good to me. It's chonky, but anyone signing up to be a maintainer should be willing to sit through it.