See also

Brand lexicon

Best practices for writing great articles and documentation

Style conventions for MUI components and products

Callouts and their usage in the docs

Our goals and principles

With everything we publish, we aim to be:

• Transparent. The majority of our communication happens on GitHub, where anyone can see exactly what we’re up to—and how we talk about it. We’re open and honest about our actions and the reasoning behind them. We err on the side of sharing more information than necessary, for the sake of clarity.
• Precise. We are an international team communicating to a global audience with widely varied expectations regarding politeness and tone. We aim for clarity and precision above all else, but not at the expense of being friendly and respectful.
• Inclusive. As maintainers of a thriving open-source community, we want to ensure that users and contributors from all backgrounds and experience levels feel welcome to participate. We are mindful to avoid discriminatory, ableist, insulting, or otherwise offensive language.
• Reassuring. It’s scary to work with a new tool—especially when you’re an early-career developer. And it’s intimidating to place your bet on a third-party tool when you need it for your core business functionality. We always want to reassure users that our products will meet their needs.
• Optimistic. We believe in the long-term viability of MUI, as well as the staying power of the React ecosystem. We want our community to know that we are here for the long haul—that they can trust our products for years to come.

<aside> 💡 "Share knowledge, not features." Whenever we write about the product, the emphasis should always be on informing our readers how and why to use any given feature. MUI and its products should usually not be the subject of the headline. The value to the reader is what matters most. From Developer Marketing Does Not Exist by Adam Duvander.

</aside>

Voice and tone

It's important for us to maintain a consistent voice across all of our communications, even though the tone may change from piece to piece and from writer to writer.

<aside> 💡 Be conversational without being frivolous. Try to sound like a knowledgeable friend who understands what the developer is trying to do. Don’t try to write exactly like you speak. But aim for a conversational tone rather than a formal one. From Google developer documentation style guide–Voice and tone

</aside>

We present ourselves as members of the community — peers, colleagues, comrades, friends, teachers, tutors, and mentors. We are knowledgeable, skilled, and talented. We understand the needs of our community because each of us individually rose from the ranks. We meet our community members with compassion, empathy, and reassurance.

We are writing for an international audience, many of whom may not have strong English language skills. We always prioritize the simplest and clearest way of expressing ourselves, in the interest of being understood by everyone in our community.

The company and its products