Refine the guidebook's treatment of inclusivity and burnout

[semioticrobotic]

Japanese translator @shu-mutou has offered an analysis of the guidebook's treatment of both inclusivity and maintainer burnout. So that these considerations didn't get overlooked in that thread, I wanted to raise them here. They are reproduced below.

---

Structural Issues in This Document

I would like to share some concerns that arose during the translation work.

Contradictory Messages

This document recommends "Release early, release often" for maintainers, while simultaneously condoning an attitude from potential contributors that they will only participate in "perfectly prepared projects."

Specifically, in the chapter "To Build Diverse Open Source Communities, Make Them Inclusive First":

• Affirmation of the stance that people won't participate in projects without a CoC
• Negative attitude toward projects with incomplete documentation
• The assumption that preparing all of these is solely the maintainer's responsibility

Many of the people quoted in this chapter are contributors with corporate support. They state they "won't contribute to unprepared projects," but isn't helping to improve projects part of their role?

What Should Be

If a project lacks a CoC or documentation, that itself is an opportunity for contribution.

Rather than "waiting for preparation," the attitude of "preparing together" is what truly creates an inclusive community, isn't it?

For example:

• When you find a project without a CoC, send a PR proposing a Contributor Covenant template
• If documentation is lacking, help organize it
• Work together to adjust it to the project's context

These are important "non-code contributions" that this document should value.

Lack of Consideration for Burnout

While this document has a chapter on "Community Manager Self-Care," the preceding chapters place additional burdens on maintainers.

Specifically:

• Create and enforce a CoC
• Prioritize documentation
• Build systems to value diverse contributions
• Establish mentorship programs
• Continuously improve

All of these are important, but there is insufficient consideration for who bears the cost of implementing them.

Improvement Proposals

If this document truly aims for sustainable communities, it should reconsider the following points:

1. Redefining "Inclusive First"

• A culture where not only maintainers but also participants contribute to building the environment
• An approach of "collaborative improvement" rather than "conditional participation"
• Encouraging an attitude of joining imperfect projects and improving them together

2. Addressing the Reality of Resource Constraints

• Realistic strategies for small-scale projects
• Guidance on "choosing what not to do"
• Concrete methods for prioritization
• Roadmaps for incremental improvement

3. Explicit Documentation of Maintainers' Rights

• The right to say "I can't do this"
• The right to publish imperfect projects
• The right to improve at one's own pace
• The right to decline contributions

4. Bidirectional Responsibility

Current structure:

Maintainers: Responsibility to prepare the environment
Contributors: Right to choose prepared environments

Desirable structure:

Maintainers: Responsibility to show project direction
Contributors: Responsibility to cooperate in environment preparation
Both: Shared responsibility to create better communities

Conclusion

As one of the burnout maintainers, I came to the following conclusion:

Without improvements to these issues, I believe this document will not prevent maintainer burnout but rather promote it in a different form.

"Inclusivity" is important, but unilaterally imposing the burden of achieving it on maintainers is not sustainable.

[semioticrobotic]

Tagging @lmaffeo and @samus-aran as authors of the respective chapters here!

[kkomazaw]

@shu-mutou
Thank you for taking the time and effort to provide such a thorough and thoughtful review.
As a translator, I am deeply grateful that you shared your insights from your experience as a maintainer, particularly your perspective as someone who has personally experienced burnout.

The points you raised are crucial issues that must not be overlooked in the translation process. I was particularly struck by your concerns regarding “the structural tendency for the burden of achieving inclusivity to implicitly fall on maintainers” and “how the accumulation of idealistic goals could ultimately undermine sustainability.”

That said, I would like to share my understanding as a translator and offer some supplementary thoughts on several points.

First, regarding your comment about “contradictory messages.”

The Open Source Way has different intended readers for each chapter. While the early chapters primarily encourage maintainers and founders to “release before perfect,” the “Inclusive First” chapter emphasizes participants' “right not to participate in unsafe environments.”

In that sense, I see it less as simultaneously demanding contradictory actions from the same position, and more as a structure presenting messages tailored to different roles side by side. However, as you pointed out, the lack of sufficient articulation on “how maintainers and participants collaborate to improve the environment in an immature project” does create room for the text to be read as emphasizing an asymmetry of responsibility. I feel this is a significant issue.

Additionally, the potential for the text to be interpreted as advocating an attitude of “not participating in projects lacking a CoC or documentation” was a challenging aspect for me as a translator.
Fundamentally, the guide as a whole positions non-code contributions—such as proposing CoCs and documenting processes—as vital forms of contribution, emphasizing collaborative efforts to improve projects.
That said, reading this chapter in isolation might obscure that underlying philosophy. Its structure could make it difficult for some readers to grasp the stance of “improving projects in their incomplete state together with participants.” This is a point that gave me pause.

Regarding concerns about burnout syndrome, especially considering the realities of Japan's OSS community, I recognize this as a very pressing point. While the “Community Manager Self-Care” chapter exists, the relationship with the expectations built up in preceding chapters is not sufficiently clarified. Consequently, it could be read as placing excessive personal responsibility on maintainers. As a translator, I feel this is a point I should be strongly mindful of.
Moving forward, from my perspective as a translator, I've come to believe that when introducing this guide in Japanese, it's necessary to supplement or annotate certain points beyond a faithful translation of the original text. These include:

• The frequent assumptions based on mature OSS projects

• Areas that may not directly apply to small-scale, individual-led, or volunteer-centered projects

• The insufficient explicit mention of maintainer rights or the “option to not do something” within the main text

This stems not from rejecting the document itself, but from a concern that supplementary guidance is needed to prevent misunderstandings or the imposition of excessive personal responsibility within the Japanese community context.

This is not to dismiss the document itself, but rather to suggest that “help guidance” on how to read it is needed within the Japanese community context to prevent misunderstandings or undue self-imposed responsibility.

I respect your judgment that continuing the review is difficult, as your honest opinion. That said, the points you raised this time provided significant insight into how this translation project should be published and shared.

Once again, I sincerely thank you for your thoughtful and thorough feedback.

[samus-aran]

Hey folks! Thanks for the ping.

There are some very valid points here and in my opinion with a little effort could be resolved - just need to align on how much we adjust.

Here’s my very high-level interpretation: these chapters were created in a silo and at different times (by different authors), so they don’t reference each other. That’s totally understandable, but as more chapters have been added, it likely calls for a quick review to see what sections would benefit from linking out to an existing chapter for extra context and make it more "interconnected".

I do feel the self-care chapter could be referenced in a number of places given how broadly applicable the advice is. That said, I want to avoid scope creep and pace myself, so if we first look at the chapter(s) mentioned, I’m sure we can make a few adjustments that address the concerns.

Just to clarify is this the chapter we should review for context to see where linking to the self-care chapter would help? Do we have any more that is required at this stage?

• Building Diverse Open Source Communities by Making Them Inclusive First

[semioticrobotic]

First of all: @samus-aran, it is so good to see your name pop up in a thread! 🤩

Just to clarify is this the chapter we should review for context to see where linking to the self-care chapter would help? Do we have any more that is required at this stage?

Yes, that's the chapter @shu-mutou was reviewing in tandem with the chapter on burnout. I really like your approach of first reviewing the chapters to note any inconsistencies and/or incompatibilities and resolving those at the outset. I have a feeling @shu-mutou would be willing to help!

Meanwhile, hopefully we can hail @lmaffeo as well.

[shu-mutou]

@semioticrobotic Thank you for taking up my issue. I hope that the discussion will be worthy of the title The Open Source Way.
@kkomazaw Thank you very much for your understanding. I completely agree with everything you have explained.
@samus-aran Thank you for considering the solution.

If an OSS project has a sufficient number of maintainers, is allowed by the company to perform maintainer duties during business hours, and is well-received and understood by the company, it may be possible to design for sufficient diversity and inclusion from the beginning and provide sufficient documentation. Alternatively, projects hosted by the OSS Foundation may have these implemented, but even if we donate OSS to the Foundation, not all OSS will be accepted. In fact, they will only accept OSS that has these implemented. Furthermore, even if we were able to make a donation, it is not certain that we would be able to maintain a sufficient project members. It is true that even in such a blessed project, maintainers feel the risk of burnout.

I believe that the spirit of open source is for everyone to support and grow new and immature OSS projects and projects that do not have enough members. I believed that this is what a document called The Open Source Way should explain, so I decided to help review the translation.

This time, I couldn't bear to read until the end, so I took a break. However, once my heart recovers, I would definitely like to try it again. At that time, I would appreciate it if you could comment again.

Thanks!!

[samus-aran]

Yes, that's the chapter @shu-mutou was reviewing in tandem with the chapter on burnout. I really like your approach of first reviewing the chapters to note any inconsistencies and/or incompatibilities and resolving those at the outset. I have a feeling @shu-mutou would be willing to help!

Meanwhile, hopefully we can hail @lmaffeo as well.

Fabulous. 😄 I will schedule some time next week to review this charter and make some suggestions on how we can be more explicit about the importance of pacing one self as a maintainer ❤️ I'll ping all involved in the PR and we can take it from there. 🌟