Communication

Where to talk about what, and the one rule that keeps an open project open.

The rule

Discord is for conversation. GitHub is for decisions.

Any significant discussion that leads toward a decision or a proposal must move to a GitHub Discussion or Issue before it becomes one, so there is a persistent, searchable, public record.

This matters more than it sounds. A project where the real decisions happen in chat is a closed project wearing an open badge: newcomers cannot catch up, people in other timezones are structurally excluded, and in two years nobody can reconstruct why a weight is 40 and not 30.

This practice is adopted from the Model Context Protocol contributor community, which articulates it better than we could.

Channels

Channel	Purpose	When to use
Discord	Real-time discussion	Quick questions, coordination, working group chatter
Discussions	Structured discussion	The project itself: roadmap, new standards, governance, votes
Issues, in the standard’s own repository	Actionable tasks	Rating changes, factor proposals, errata, bugs
The standard’s SECURITY.md	Sensitive issues	Never post these publicly

Anything about a specific standard belongs in that standard’s repository — for OARS, opencitadel/OARS. Anything about the project belongs here.

All communication is governed by the Code of Conduct. We expect respectful, professional, and inclusive interaction on every channel.

Discord

The Citadel Discord is for contributor discussion and collaboration. It is not a support desk for Microsoft Entra, Microsoft Graph, or any product built on these standards.

Good uses

• Working group discussion — #oars, and a channel per standard as they form
• Onboarding and contribution guidance for newcomers
• Feedback and collaborative brainstorming before something is written up
• Coordination: who is picking up what, and when we are meeting

Please avoid

• General Entra or Graph support questions — the Microsoft Q&A forums and the Microsoft Tech Community are better places, and you will get better answers
• Product marketing. Keep discussion vendor-neutral. Mentioning tools as concrete examples is fine and often useful; pitching them is not
• Decision-making. See the rule at the top

Private channels exist only for security reports under embargo and for people matters such as Code of Conduct reports. They are temporary incident rooms, not a back room for routine work. Any decision reached in one that affects the community is written up publicly.

GitHub Discussions

For structured, long-form discussion where the outcome should be findable later.

• Roadmap planning and milestones
• Announcements and release notes
• Community polls, consensus-building, and formal votes
• Proposals that need context and rationale before they become a pull request

GitHub Issues

For specific, actionable work, in the repository of the standard concerned. Each standard provides templates for the kinds of change it expects. OARS, for example, has rating change request, factor proposal, and errata — each asking for the evidence a reviewer will need anyway.

Issues on this repository are for the project itself: process, tooling, and the community.

Meetings

Working groups meet as needed rather than on a fixed cadence. Meetings are announced in Discord and in GitHub Discussions at least 72 hours ahead, are open to anyone who wants to attend, and produce written notes posted to GitHub Discussions.

A decision reached in a meeting is not final until it is written up and has had its review period. Attending a call cannot be a prerequisite for having a say.

---

Source: community/COMMUNICATION.md