Add Sphinx navigation, zh_CN translations, and content formatting fixes

attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md

@@ -144,9 +144,9 @@ Rather than keeping Redis's prior BDFL style, Gottlieb and Agra built a new, lig
 
 Regardless of your own project's governance model, you must include a way to train key contributors to assume leadership roles. This achieves three key goals:
 
-1.  Helping new contributors learn how they can grow
-2.  Rewarding contributors who own key aspects of the project
-3.  Preventing maintainer burnout
+1. Helping new contributors learn how they can grow
+2. Rewarding contributors who own key aspects of the project
+3. Preventing maintainer burnout
 
 This last point is noteworthy: Sanfilippo said when he stepped down from Redis that despite his passion for coding, he never aspired to maintain a project. Without new leaders to step up—and documentation sharing how contributors can assume such roles—maintainers risk either working on projects when they no longer want to or having the project stall. Likewise, the project risks missing an opportunity to give interested contributors a chance to step up.
 

attracting-users/index.md

@@ -0,0 +1,10 @@
+# Attracting Users
+
+```{toctree}
+:maxdepth: 1
+
+README
+communication-norms-in-open-source-software-projects
+building-diverse-open-source-communities-by-making-them-includive-first
+```
+

getting-started/essentials-of-building-a-community.md

@@ -174,9 +174,9 @@ Hopefully, your investments in an open source software community will lead that
 
 Some of these key metrics might include:
 
-- The number of bugs fixed and the number of changes accepted over a specific time period (it's not bad for a project to have a lot of bug reports. every project has bugs, so a steady stream of bug reports shows that people are using the product—but the bugs should get fixed!)
-- Numbers of project downloads (many people download a product to try it out and then discard it, so use other measures if possible to gauge the real growth of the user base—for instance, the number of people participating on forums and the number of questions asked)
-- Your community's mix of contributor experience (have the right mix of project members, some who have been on the project for a long time and can provide institutional memory, along with more recent recruits who provide new energy)
+* The number of bugs fixed and the number of changes accepted over a specific time period (it's not bad for a project to have a lot of bug reports. every project has bugs, so a steady stream of bug reports shows that people are using the product—but the bugs should get fixed!)
+* Numbers of project downloads (many people download a product to try it out and then discard it, so use other measures if possible to gauge the real growth of the user base—for instance, the number of people participating on forums and the number of questions asked)
+* Your community's mix of contributor experience (have the right mix of project members, some who have been on the project for a long time and can provide institutional memory, along with more recent recruits who provide new energy)
 
 ## Conclusion
 This chapter offered an overview of essential considerations one should make when determining whether to start an open source software community and deciding how best to architect that community.

getting-started/index.md

@@ -0,0 +1,12 @@
+# Getting Started
+
+```{toctree}
+:maxdepth: 1
+
+README
+community-101
+essentials-of-building-a-community
+building-a-strategy
+new-project-checklist
+```
+

growing-contributors/constructing-an-onboarding-experience.md

@@ -77,30 +77,30 @@ Your project will have any number of contributor pathways specific to it, but th
 
 *Community-focused* pathways are opportunities for contribution that may not require specialized technical knowledge on the part of participants. These are pathways focused on helping new contributors document the project, raise awareness of and market the project, plan community meetings and events, etc.—all extraordinarily important aspects of a project's eventual success. Examples include:
 
-1.  Documenting workflow and governance processes
-2.  Onboarding and mentoring new members
-3.  Localizing content into various languages
-4.  Copywriting (for website, newsletters, blogs)
-5.  Managing social media
-6.  Organizing events
+1. Documenting workflow and governance processes
+2. Onboarding and mentoring new members
+3. Localizing content into various languages
+4. Copywriting (for website, newsletters, blogs)
+5. Managing social media
+6. Organizing events
 
 *Technically focused* contributor pathways, on the other hand, are contributions requiring specialized knowledge of software development (often in a particular computing language). These pathways are focused on enchancing or refining the body of software a community maintains. Examples include:
 
-1.  Adding new features and documentation
-2.  Fixing existing bugs and triaging issues
-3.  Refactoring existing work to improve it
-4.  Performing quality assurance
-5.  Improving user interface and user experience
-6.  Release engineering
-7.  Creating and maintaining project roadmap
-8.  Code and user interface localization
+1. Adding new features and documentation
+2. Fixing existing bugs and triaging issues
+3. Refactoring existing work to improve it
+4. Performing quality assurance
+5. Improving user interface and user experience
+6. Release engineering
+7. Creating and maintaining project roadmap
+8. Code and user interface localization
 
 When assessing your project's contributor pathways, ask yourself: Does your project currently offer new (and existing) contributors opportunities to contribute rewardingly to (or even take ownership of) work in each of these areas? If not, one general way to begin expanding your project is by making concerted efforts to formalize, refine, document, and advertise these contributor pathways.
 
 We call these "pathways" because they allow participants to deepen investment in the community *gradually* so they don't feel overwhelemed and can acclimate themselves to the project's processes and culture as they become more involved. Ideally, as your community matures, it will construct pathways that incrementally confer more responsibility and authority on contributors. Contributors following your project's contributor pathway related to events, for example, probably won't get started by taking sole responsibility for your community's flagship annual event. But they might work with experienced community members on planning that event, taking charge of securing a venue, advertising, registration, and more.
 
 ## Resources: Onboarding examples from open source communities
 
-1.  [OpenStack Upstream Institute](https://docs.openstack.org/upstream-training/)
-2.  [Kubernetes Contributor Experience Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-contributor-experience)
-3.  [GitLab Merge Request Coach](https://about.gitlab.com/job-families/expert/merge-request-coach/)
+1. [OpenStack Upstream Institute](https://docs.openstack.org/upstream-training/)
+2. [Kubernetes Contributor Experience Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-contributor-experience)
+3. [GitLab Merge Request Coach](https://about.gitlab.com/job-families/expert/merge-request-coach/)

growing-contributors/creating-a-culture-of-mentorship.md

@@ -89,11 +89,11 @@ If this matches your projects's version of sustainable, then a mentoring program
 
 Self-sustainability is an important focus for a mentoring program. And don't think anyone goes from "mentoring people" to "a mentoring program" by accident. Here's the argument:
 
-1.  If we can agree that lowering the barriers for entry into a project is key to bringing in new people; and
-2.  If we can agree that people coming into a new project benefit from having one or more people they feel permitted and even encouraged to ask questions and learn from; and
-3.  If we can agree new people having lackluster or negative interactions with existing project members is likely to drive the new people away; and
-4.  If we can agree that having a person (mentor, friend) for new people to turn to is a way to prevent the driving-away and especially prevent *silent segfaults* (people just disappearing with no explanation);
-5.  Then we can see that doing mentoring with even a tiny bit of repeatable process support is going to yield better, more satisfying results than an ad-hoc process.
+1. If we can agree that lowering the barriers for entry into a project is key to bringing in new people; and
+2. If we can agree that people coming into a new project benefit from having one or more people they feel permitted and even encouraged to ask questions and learn from; and
+3. If we can agree new people having lackluster or negative interactions with existing project members is likely to drive the new people away; and
+4. If we can agree that having a person (mentor, friend) for new people to turn to is a way to prevent the driving-away and especially prevent *silent segfaults* (people just disappearing with no explanation);
+5. Then we can see that doing mentoring with even a tiny bit of repeatable process support is going to yield better, more satisfying results than an ad-hoc process.
 
 Once you agree that even a lightweight program is better than an ad-hoc process, we're going in the right direction. With this in mind, here are a few absolute must-have elements to include in your mentoring program.
 

growing-contributors/index.md

@@ -0,0 +1,15 @@
+# Growing Contributors
+
+```{toctree}
+:maxdepth: 1
+
+README
+from-users-to-contributors
+what-is-a-contribution
+constructing-an-onboarding-experience
+creating-a-culture-of-mentorship
+project-and-community-governance
+understanding-community-roles
+community-manager-self-care
+```
+

growing-contributors/understanding-community-roles.md

@@ -36,13 +36,13 @@ If no one is working on a document, and the community or project leaders support
 
 At this point, make a formal announcement, such as by creating an issue. A due date is recommended, to provide some pressure to finish the document. Remember that a document needs to be reviewed, which could add several weeks to the project. It is also useful to create milestones, which could include:
 
-1.  Start writing
-2.  Circulate first draft
-3.  End of review period for first draft
-4.  Circulate final draft
-5.  End of review period for final draft
-6.  Submitted for approval
-7.  Approved and published
+1. Start writing
+2. Circulate first draft
+3. End of review period for first draft
+4. Circulate final draft
+5. End of review period for final draft
+6. Submitted for approval
+7. Approved and published
 
 To be accepted into a project, the leadership or advisor group responsible for the project must approve it. These leaders should be liberal in approving documentation projects, because any new document that is relevant to a project will usually prove useful to at least some members.
 

guiding-participants/index.md

@@ -0,0 +1,10 @@
+# Guiding Participants
+
+```{toctree}
+:maxdepth: 1
+
+README
+why-people-participate-in-open-source-communities
+incentivizing-and-rewarding-participants
+```
+

index.md

@@ -0,0 +1,27 @@
+# The Open Source Way
+
+```{toctree}
+:maxdepth: 2
+:titlesonly:
+:caption: Guidebook
+
+README
+presenting-the-open-source-way
+getting-started/index
+attracting-users/index
+guiding-participants/index
+growing-contributors/index
+measuring-success/index
+```
+
+```{toctree}
+:maxdepth: 1
+:titlesonly:
+:caption: Project information
+
+CONTRIBUTING
+TRANSLATION
+CODE_OF_CONDUCT
+CONTRIBUTORS
+LICENSE
+```

locales/zh_CN/LC_MESSAGES/CODE_OF_CONDUCT.po

@@ -0,0 +1,178 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C)
+# This file is distributed under the same license as the The Open Source Way
+# package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, 2026.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: The Open Source Way \n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 1970-01-01 00:00+0000\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language: zh_CN\n"
+"Language-Team: zh_CN <LL@li.org>\n"
+"Plural-Forms: nplurals=1; plural=0;\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Generated-By: Babel 2.18.0\n"
+
+#: ../../CODE_OF_CONDUCT.md:1
+msgid "Open Source Way Contributor Code of Conduct"
+msgstr "开源之道贡献者行为准则"
+
+#: ../../CODE_OF_CONDUCT.md:3
+msgid "Our Pledge"
+msgstr "我们的承诺"
+
+#: ../../CODE_OF_CONDUCT.md:5
+msgid ""
+"In the interest of fostering an open and welcoming environment, we as "
+"contributors and maintainers pledge to making participation in our project "
+"and our community a harassment-free experience for everyone, regardless of "
+"age, body size, disability, ethnicity, sex characteristics, gender identity "
+"and expression, level of experience, education, socio-economic status, "
+"nationality, personal appearance, race, religion, or sexual identity and "
+"orientation."
+msgstr "为了促进一个开放和欢迎的环境，我们作为贡献者和维护者承诺，使参与我们的项目和社区成为一个无骚扰的体验，适用于每个人，无论年龄、身体大小、残疾、种族、性别特征、性别认同和表达、经验水平、教育、社会经济地位、国籍、个人外貌、种族、宗教或性身份和取向。"
+
+#: ../../CODE_OF_CONDUCT.md:12
+msgid "Our Standards"
+msgstr "我们的标准"
+
+#: ../../CODE_OF_CONDUCT.md:14
+msgid ""
+"Examples of behavior that contributes to creating a positive environment "
+"include:"
+msgstr "有助于创造积极环境的行为示例包括："
+
+#: ../../CODE_OF_CONDUCT.md:17
+msgid "Using welcoming and inclusive language"
+msgstr "使用欢迎和包容的语言"
+
+#: ../../CODE_OF_CONDUCT.md:18
+msgid "Being respectful of differing viewpoints and experiences"
+msgstr "尊重不同的观点和经验"
+
+#: ../../CODE_OF_CONDUCT.md:19
+msgid "Gracefully accepting constructive criticism"
+msgstr "优雅地接受建设性批评"
+
+#: ../../CODE_OF_CONDUCT.md:20
+msgid "Focusing on what is best for the community"
+msgstr "专注于对社区最有利的事情"
+
+#: ../../CODE_OF_CONDUCT.md:21
+msgid "Showing empathy towards other community members"
+msgstr "对其他社区成员表现出同情"
+
+#: ../../CODE_OF_CONDUCT.md:23
+msgid "Examples of unacceptable behavior by participants include:"
+msgstr "参与者不可接受的行为示例包括："
+
+#: ../../CODE_OF_CONDUCT.md:25
+msgid ""
+"The use of sexualized language or imagery and unwelcome sexual attention or "
+"advances"
+msgstr "使用性别化语言或图像以及不受欢迎的性关注或进攻"
+
+#: ../../CODE_OF_CONDUCT.md:27
+msgid "Trolling, insulting/derogatory comments, and personal or political attacks"
+msgstr "网络喷子、侮辱性/贬损性评论，以及个人或政治攻击"
+
+#: ../../CODE_OF_CONDUCT.md:28
+msgid "Public or private harassment"
+msgstr "公开或私下骚扰"
+
+#: ../../CODE_OF_CONDUCT.md:29
+msgid ""
+"Publishing others' private information, such as a physical or electronic "
+"address, without explicit permission"
+msgstr "在未获得明确许可的情况下发布他人的私人信息，例如物理或电子地址"
+
+#: ../../CODE_OF_CONDUCT.md:31
+msgid ""
+"Other conduct which could reasonably be considered inappropriate in a "
+"professional setting"
+msgstr "其他在专业环境中合理被认为不当的行为"
+
+#: ../../CODE_OF_CONDUCT.md:34
+msgid "Our Responsibilities"
+msgstr "我们的责任"
+
+#: ../../CODE_OF_CONDUCT.md:36
+msgid ""
+"Project maintainers are responsible for clarifying the standards of "
+"acceptable behavior and are expected to take appropriate and fair corrective"
+" action in response to any instances of unacceptable behavior."
+msgstr "项目维护者负责澄清可接受行为的标准，并预计在任何不可接受行为的实例中采取适当和公正的纠正措施。"
+
+#: ../../CODE_OF_CONDUCT.md:40
+msgid ""
+"Project maintainers have the right and responsibility to remove, edit, or "
+"reject comments, commits, code, wiki edits, issues, and other contributions "
+"that are not aligned to this Code of Conduct, or to ban temporarily or "
+"permanently any contributor for other behaviors that they deem "
+"inappropriate, threatening, offensive, or harmful."
+msgstr "项目维护者有权和责任删除、编辑或拒绝与本行为准则不一致的评论、提交、代码、维基编辑、问题和其他贡献，或因其他他们认为不当、威胁、冒犯或有害的行为而暂时或永久禁止任何贡献者。"
+
+#: ../../CODE_OF_CONDUCT.md:46
+msgid "Scope"
+msgstr "范围"
+
+#: ../../CODE_OF_CONDUCT.md:48
+msgid ""
+"This Code of Conduct applies within all project spaces, and it also applies "
+"when an individual is representing the project or its community in public "
+"spaces. Examples of representing a project or community include using an "
+"official project e-mail address, posting via an official social media "
+"account, or acting as an appointed representative at an online or offline "
+"event. Representation of a project may be further defined and clarified by "
+"project maintainers."
+msgstr "本行为准则适用于所有项目空间，并且在个人代表项目或其社区在公共空间时也适用。代表项目或社区的示例包括使用官方项目电子邮件地址、通过官方社交媒体账户发布信息，或在在线或离线活动中担任指定代表。项目的代表性可能由项目维护者进一步定义和澄清。"
+
+#: ../../CODE_OF_CONDUCT.md:55
+msgid "Enforcement"
+msgstr "执行"
+
+#: ../../CODE_OF_CONDUCT.md:57
+msgid ""
+"Instances of abusive, harassing, or otherwise unacceptable behavior may be "
+"reported by contacting the project team at ombuds@theopensourceway.org. All "
+"complaints will be reviewed and investigated and will result in a response "
+"that is deemed necessary and appropriate to the circumstances. The project "
+"team is obligated to maintain confidentiality with regard to the reporter of"
+" an incident. Further details of specific enforcement policies may be posted"
+" separately."
+msgstr ""
+"虐待、骚扰或其他不可接受行为的实例可以通过联系项目团队 ombuds@theopensourceway.org "
+"进行报告。所有投诉将被审查和调查，并将根据情况采取必要和适当的回应。项目团队有义务对事件报告者保持保密。具体执行规定的进一步细节可能会单独发布。"
+
+#: ../../CODE_OF_CONDUCT.md:64
+msgid ""
+"Project maintainers who do not follow or enforce the Code of Conduct in good"
+" faith may face temporary or permanent repercussions as determined by other "
+"members of the project's leadership."
+msgstr "未能善意遵循或执行行为准则的项目维护者可能会面临其他项目领导成员决定的临时或永久后果。"
+
+#: ../../CODE_OF_CONDUCT.md:68
+msgid "Attribution"
+msgstr "归属"
+
+#: ../../CODE_OF_CONDUCT.md:70
+msgid ""
+"This Code of Conduct is adapted from the [Contributor Covenant][homepage], "
+"version 1.4, available at https://www.contributor-covenant.org/version/1/4"
+"/code-of-conduct.html"
+msgstr ""
+"本行为准则改编自 [贡献者公约][homepage]，版本 1.4， 可在 https://www.contributor-covenant.org"
+"/zh-cn/version/3/0/code_of_conduct/ 获取。"
+
+#: ../../CODE_OF_CONDUCT.md:75
+msgid ""
+"For answers to common questions about this code of conduct, see https://www"
+".contributor-covenant.org/faq"
+msgstr "有关本行为准则的常见问题的答案，请参见 https://www.contributor-covenant.org/faq"