风格指南
本指南用于帮助您了解术语表的受众，定义结构，必需的颗粒度，以及如何保持一致的样式。
本开源办公室术语表遵循如下规则：
- 使用简单的、易于理解的语言，避免使用技术术语和流行语
- 杜绝口语
- 使用准确和具体的语言
- 避免缩写
- 少用被动语态
- 尽量以主动形式表达
- 引号外避免使用感叹号
- 避免夸大
- 避免冗余
- 要简洁
受众
本术语表是为技术和非技术用户编写的。 请确保定义以简单明了的方式进行解释，并不要假设技术知识。下面在“定义”下进一步做出说明。
最小可行定义
我们的目标是让任何人都能够轻松理解开源办公室术语。 因此，我们专注于简单。 这意味着使用清晰简单的语言，配以任何使用技术的人都能够理解的示例（更多内容如下），同时提供至少从技术角度来看的最小可行定义。 我们不希望省略上下文和示例 — 毕竟这些能帮助读者理解概念 — 但如果不需要技术细节来理解，我们会跳过。 目标是不要把事情搞得太复杂。一旦读者理解了基本概念，其他资源将帮助他们深入挖掘。 这部分不在本术语表的范围内。
定义模板
每个术语都储存在 markdown 文件中，并遵循此模板：
---
title:
status:
category:
---
## 是什么
对技术或概念的简洁摘要。
## 它要解决的问题
一小段关于它所解决问题的描述。
## 它有何帮助
几段关于它如何解决问题的描述。
标题
标题标签将始终位于定义布局的顶部，其值应为首字母大写的格式。
---
title: 定义模板
状态
状态标签将跟在标题标签之后。状态标签表示定义是否经过彻底审查或需要更多工作。
有效的值是：
- Completed(完成)
- Feedback Appreciated(感谢反馈)
- Not Started(未开始)
你可以随时针对已完成的定义提出疑修。当定义处于变化阶段时，其状态将更改为感谢反馈。
---
title: 定义模板
status: Feedback Appreciated
分类标签
分类标标签跟在状态标签之后。 为了使标签具有意义，并对用户有所帮助，我们将严格使用它们。 使用太多标签只会削弱其含义。 除了“基本”意味着必须要理解其他云原生概念的术语之外，大多数术语可能只有一个标签。
注意：请不要引入新的标签，除非维护者批准。当您向条目添加分类标签时，请确保它们与下面列出的（单数，无拼写错误）完全相同。
目前的分类标签有
- application(应用)
- architecture(架构)
- fundamental(基础)
- infrastructure(基础设施)
- methodology(方法论)
- networking(网络)
- property(属性)
- security(安全)
---
title: 定义模板
status: Feedback Appreciated
tags: ["tag 1"], ["tag 2"]
---
定义
质量至上
如果合并了，你的提交就是开源办公室对该术语的官方定义（直到有人对其进行优化）。 创建一个满足开源办公室高标准的术语不能草率 — 质量需要时间和努力。
自己做研究：即便您确信您知道这个术语，也要验证您的理解是正确的。 我们经常在组织中以一定方式使用术语，但这种方式可能无法反应全貌。 当你做研究，特别是你对术语不是很熟悉时，请使用多个资源。 很多定义是片面的，特别是由供应商提供的那些。 术语表必须包含供应商中立的，全球接受的定义。
不要剽窃。同样的规则适用于术语表和任何其他任何严肃的出版物。 不要复制粘贴别人的工作，除非你正在引用并贡献给他们。 如果您喜欢一个定义中的一部分，请用自己的语言来组织。
参考权威资源。可以的话，链接到权威资源，如项目文档。 注意我们不能链接到供应商开发的内容。
保持简单
术语表旨在以简单的词语解释复杂的概念，这是出乎意料难以完成的任务，可能需要多次修订。 在起草您的定义时，请记得考虑读者。 避免使用行业术语和流行语 ——你可能会不自觉地使用它们，这时需要对自己的表述进行调整和修正。
在适当的时候，使用现实世界的例子来帮助读者（尤其是非技术人员）更好地理解你所解释的概念何时以及为什么是相关的。
在您的定义中使用时，始终链接到现有的词汇表术语（只有首次提到时应添加超链接）。
示例：查看服务网格定义中的“是什么”部分。 它与微服务、服务、可靠性和可观察性的定义有关。 此外，它使用一个真实世界的例子，将微服务环境中的网络挑战（非技术人员无法理解的内容）与wifi问题（任何使用笔记本电脑的人都能理解）进行了比较。 在可能的情况下，尽量建立这种联系。
从您喜欢的文字处理软件开始
我们建议先用Google、LibreOffice、Word等软件写一篇文档，让它静置几天，然后再回来修订。 这样可以帮助您捕捉到可以用更简单易懂的表述来改进的地方。 以及，在提交PR之前，确保运行拼写检查。
为了确保在处理一个术语时没有人其他人提交PR，请确保认领一个问题（或创建一个问题），并确认其已经分配给您了。 有关更多信息，请参阅如何贡献文档。
在开始之前，请阅读一些已发布的术语 以获取一些关于颗粒度和难点以及示例什么时候合适的感觉。
审查流程：期待什么
请注意，目前我们只有三位维护者在业余时间进行审查。 有时，我们可能会快速地审查术语；而有时可能需要一些时间 —— 我们感谢您的耐心。 如果您有任何问题，请在 #glossary Slack 频道与我们联系 （关于在哪里和如何找到它，请参考我们的如何贡献文档）。
我们的目标是使术语表成为可能是最佳的资源。 一旦您提交了 PR，我们可能会要求进行一个或多个修订。 不要沮丧 —— 这对许多 PR 都是一样的。 这种反复和我们的合作将确保您的贡献成为一个真正有用的定义，受全球读者阅读和参考。