Linux 文档项目审阅者指南
Emma Jane Hogbin
David Merrill
david -AT- lupercalia.net
Joy Yokley
2004-04-19
| 修订历史 | ||
|---|---|---|
| 修订版 1.4.2 | 2004-05-24 | 修订者：EJH |
| 修正了拼写错误。 | ||
| 修订版 1.4.1 | 2004-04-19 | 修订者：EJH |
| 对语言和标记进行了细微更新，强调了审阅的报告程序。还更改了审阅的顺序以反映实际程序（技术审阅、语言审阅和最终的元数据审阅）。 | ||
| 修订版 1.4 | 2004-04-18 | 修订者：EJH |
| 更新了语言审阅： clarified use of capitals（澄清了首字母大写的使用）, 并添加了一个新要求，即拉丁语缩写始终使用其英语对应词。 | ||
| 修订版 1.3 | 2004-01-31 | 修订者：EJH |
| 添加了元数据和标记审阅信息。 | ||
| 修订版 1.2 | 2003-11-09 | 修订者：TMM |
| 更新了内容、URL、邮件列表，转换为 XML。 | ||
| 修订版 1.1 | 2001-05-12 | 修订者：DCM |
| 细微的错误修复。 | ||
| 修订版 1.0 | 2001-05-01 | 修订者：jy |
| 初始版本发布。 | ||
1. 简介
LDP 审阅项目是 “工作组” Linux 文档项目 的一部分，其目标是提高 LDP 文档的质量。我们正从两个不同的角度来实现该目标：审阅新提交的文档和审阅现有文档。我们欢迎您提出改进建议。
我们为编辑建立了一个邮件列表；订阅说明请访问 http://www.tldp.org/mailinfo.html#maillists。
1.1. 版权和许可
本文档版权归 David C. Merrill, Ph.D. 于 2001 年所有，版权归 Emma Jane Hogbin 于 2004 年所有。
在 GNU 自由文档许可证 1.1 版或自由软件基金会发布的任何后续版本的条款下，允许复制、分发和/或修改本文档；不包含不变节，不包含封面文本，也不包含封底文本。许可证副本包含在题为 “GNU 自由文档许可证” 的章节中。
发送反馈至<discuss@en.tldp.org>。请在您的电子邮件中注明本文档的标题。
2. 审阅新提交的文档
此审阅项目将在 LDP 的整个生命周期内持续进行。该过程将作为提交给 LDP 的新文档的前端质量保证审阅。理想情况下，文档将在提交给 LDP 后一周内进行审阅。
此项工作的协调员将向列表公布或通知个别审阅成员新的文档提交。协调员将尝试将文档引导给在与文档相同的技术领域具有知识的审阅者。如果审阅者不是该特定领域的技术专家，并且需要技术问题解答，则将指定一名技术专家，他将能够解决任何技术问题或疑问。
审阅者同意处理文档后，他们将有一周的时间完成审阅。如果他们无法在该时间范围内完成审阅，他们需要告知协调员他们的困难，以便可以通知作者该问题。由于这些审阅需要快速进行，因此有时审阅者将更有能力接受审阅工作。
在审阅新提交的文档时，请参阅本指南的 第 5 节 和 第 6 节 部分，了解要验证和更正的信息类型。作为审阅者，您需要从 CVS [1] 中检出文档，并进行任何必要的更改。如果更改范围广泛，或者文档存在明显的和根本性的致命错误，请联系协调员并告知他们问题所在。进行更改后，审阅者将更新次版本号，在修订历史中添加新条目，并将他们的名字作为文档的 “编辑” 包括在内。这些更改将被提交到 CVS，如果作者没有 CVS 访问权限，则原始副本将发送给文档的作者。
3. 审阅现有文档
该项目将侧重于审阅 LDP 上已存在的文档。我们的目标是实施一项质量管理计划，以确保我们提供最新、准确、易于阅读的文档。此过程将在 LDP 的整个生命周期内持续进行。最初，我们将尝试审阅当前 LDP 上的所有文档。在我们完成现有文档的审阅后，我们将安排后续审阅的日期。通过在其在 LDP 的整个生命周期内不断审阅文档，我们帮助确保读者获得 Linux 文档的最佳体验。
除了提高文档本身质量的主要目标之外，我们还将收集关于文档集合的数据，以便存储在某种数据库中，以方便对文档集合进行持续管理。但是，审阅的这个阶段仍在定义中；关于具体细节以及如何衡量这些数据的信息将在未来添加。
以下是您在开始审阅 LDP 的现有文档之前应遵循的一些一般准则。请尽量在您注册审阅文档后的两周内完成文档审阅。
3.1. 选择文档
有很多文档需要审阅。最重要的是您与其他审阅者协调您的工作。为了协调工作，我们为审阅者设置了一个邮件列表。
在您开始审阅文档之前，请通知编辑列表（订阅说明请访问 http://www.tldp.org/mailinfo.html#maillists）。我们希望确保您的工作 направлено туда, где это больше всего необходимо 和 где это будет наиболее полезно. 当然，您可能具有特定的专业知识领域，这将一定程度上决定您的选择。您可以在列表上请求分配任务，或者您可以自己选择一个并只需让邮件列表知道您在做什么。
3.2. 许可问题
确保您拥有处理文档的合法权利。如果它是在明确授予此类权利的自由许可下获得许可的，则您没有问题。否则，您需要联系作者并获得许可。
如果您不打算实际更改任何内容，而只是报告文档的状态，那么无论许可证如何，您都不需要获得许可。当然，无论如何写信给作者仍然是礼貌和明智的。
如果文档缺少版权和/或许可证，建议您建议作者选择并应用一个。有关许可的更多信息，请参见 第 7 节
4. 同行评审
当作者向 LDP 提交新文档时，监控提交电子邮件列表的人员将建议作者将其草稿发布到讨论列表以进行初始同行评审，然后再发布。除了确定文档是否彻底涵盖了主题 matter（事项）之外，同行还可以指出文档集中已有的类似作品，在这种情况下，新作者可能希望联系现有作品的维护者。
作为审阅团队的成员，您将识别出同行评审文档，作者已将其提交到讨论列表，专门请求反馈以将其指南包含在文档集中。任何订阅讨论列表的人员都可以执行此审阅 (www.tldp.org/mailinfo.html#maillists)。
5. 技术准确性审阅
确保文档中陈述的事实是正确的、有帮助的并且与主题相关。
要进行技术准确性审阅，您确实需要了解您的主题 matter（事项），可能与原始作者一样好或更好。使用可用于您的主题的任何其他文档，包括手册页、程序文档、其他印刷书籍等。您也可以使用关于该主题的邮件列表，要求第三方验证您有疑问的某些事实。
在进行这种类型的审阅时，请考虑信息是否仅对某些类型的硬件或软件有效。如果是这种情况，请务必在文档内的文档中注明文档的局限性，无论是在摘要中还是在文档开头的注释中。例如，如果文档中的解决方案仅与一种类型或品牌的硬件相关，请确保定义了该局限性。这将防止读者尝试将某种类型的技术应用于它不起作用的应用程序或情况。
同样的道理也适用于读者的先决知识。如果假定或需要主题的先验知识，作者应在文档开头的某处说明，并且要求作者提供“资源”部分以供进一步阅读，以使读者更接近所需的信息，这将很有帮助。
6. 语言审阅
由于作者来自各种背景，因此文档中可能存在需要修复的问题。作者可能在其主题领域非常知识渊博，但写作能力不强，或者他们可能是优秀的作家，但语言可能不完全流利。语言审阅通过关注使文档更易于用户阅读和理解的语言问题来解决这些类型的问题。文档中可能发生的一些问题包括句子结构差、语法、组织、清晰度和拼写错误。
如果您正在进行语言审阅，您应该精通该语言和语言结构。您需要同时考虑文档的逻辑和语法。语言审阅的主要目标是识别和纠正可能导致文档的读者/用户感到困惑的区域。为此，当您有疑问时，您当然可以使用语言和语法参考书，例如词典和手册。
尽管此审阅确实涉及语言的结构和表达，但您不应尝试清除文档中的个性和特点，以使其 “听起来更好” 或更技术化。僵硬、缺乏幽默感的语言和结构不是这里的目标。同样，您的目标应该是使文档在拼写和语法上清晰、明确和正确。
评估项目
拼写。 拼写应符合术语的标准化英语拼写。对于语言中新出现的且尚未标准化的单词（例如，社区中普遍接受的技术 Linux 术语），请遵循该术语最常见的拼写。
注意 由于英语有两种普遍接受的形式，因此此审阅不应优先考虑美式英语拼写而不是英式英语拼写，反之亦然。例如，如果作者使用英式英语并使用单词 “realise”，您不应仅因为您说/写美式英语而将该单词的拼写更改为 “realize”。
语法。 为了进行此审阅，语法应解决诸如主谓一致、代词/先行词一致等问题。HOWTO 中常见的且令人困惑的错误之一是不明确的代词先行词。
例如，说 “You will need to set several parameters in the config file to make it compile correctly. The ones you choose to set make a big difference.” 在此示例中，听起来好像是配置文件正在编译，并且需要重新阅读该短语才能清楚 “The ones” 指的是参数。
与此类似，许多为 LDP 写作的作者使用笑脸和感叹号，而在正式文档或语法手册中永远不会接受它们。此时要遵循的一般规则是保留笑脸和不必要的标点符号，除非它们干扰读者对所解释概念的理解。这背后的理由是为了保护 LDP 文档更具对话性的语气。
大写字母的使用。单词 “HOWTO” 应始终全部大写，且不带连字符。文档的标题和章节标题可以遵循两种约定之一，但必须在整个文档中保持一致。标题可以仅将第一个单词大写，也可以将每个单词大写。在第二种情况下，标题中唯一不capitalize（大写）的单词是介词、冠词和proper nouns（专有名词），否则这些词也不会大写（例如：insmod）。其他大写应遵循标准英语规则。
清晰度。 对清晰度的判断有时很难做出。评估清晰度的一个成功策略是问问题 “如果我尚不知道此信息，那么从本文档中可以清楚地解释清楚吗？” 如果您感到困惑，而您通常已经理解了作者试图表达的意思，那么很有可能对于第一次阅读文档的人来说，解释确实令人困惑。如果您遇到这种情况，并且您真的不知道如何纠正技术解释，或者您担心您的更改可能会影响文档的含义，请向技术专家寻求帮助。如果没有技术专家可用，或者没有人回应您的请求，请在审阅中注明需要的更改，并标记这些问题需要在技术审阅中解决。
组织。 在某些情况下，文档确实可以从不同的结构中受益。当这些问题干扰对文档中信息的理解时，您应该解决这些问题。如果文档在执行过程后给出了背景信息，那么对于读者在执行任务之前充分考虑他或她需要的信息来说，这可能为时已晚。寻找可能使读者感到困惑或误导的文档组织。这些将是您想要解决的问题类型。一旦确定了这些问题，最好让作者知道您的理由并与他或她讨论重大更改。
句子结构。 在某种程度上，句子结构问题在语法部分中讨论；但是，还有一些其他问题在语法上没有错误，但确实干扰了读者对材料的理解。其中最明显的一个是stacked prepositional phrases（堆叠介词短语）。当文档的可读性受到影响时，堆叠介词短语就会成为问题，因为它越来越不清楚句子的主语和动作是什么。在某些情况下，需要更精确的描述符，或者需要将句子从难以理解的长句更改为两个或三个更易于阅读的句子。
可读性。 这个领域在某种程度上是主观的。对于一个人来说相当readable（可读）的材料对于另一个人来说可能会令人困惑。由于这是一个价值判断，因此在标记作者作品的可读性时应谨慎。当基于可读性进行判断时，请意识到您可能正在处理风格偏好。在 LDP 的当前阶段，没有作者需要遵循的既定风格或文体规则。在评估可读性时，您必须考虑文档的写作方式是否真的干扰了读者对信息的理解。如果您得出的答案是 “不，但这听起来不像我认为的那样。”，那么您可能不应该重写文本以使其对您听起来更好。
标题。标题应采用适当的标题大小写。此通用原则是标题中除介词和冠词（如果冠词是标题中的第一个单词，则将其大写）外的所有单词都大写。单词 HOWTO 应全部大写。单词 HOWTO 中不应包含连字符。版本不应包含在标题中。
日期格式。日期应采用标准 ISO 格式，即 YYYY-MM-DD。
术语的统一使用。 由于您正在审阅的指南可能充满了对读者来说是新的信息，因此文档中讨论的术语保持统一非常重要。例如，在文档的某个部分中以一个名称引用部件或参数，然后在文档的另一部分中以另一个名称（或尚未解释的缩写）调用它，这会让读者感到困惑。确保术语在整个文档中保持一致，这对于帮助读者理解文档大有帮助。
首字母缩略词或俚语的定义。 计算机技术领域的术语和语言变化迅速。在审阅文档时，您可能会发现许多正在讨论的术语在您熟悉的任何词典或技术参考中都不是有效词。在这种情况下，您需要搜索术语并查找它们是否实际上是通用 Linux 社区中接受的术语。不太熟悉的术语应在术语首次出现后立即定义。如果俚语会导致读者对术语的内涵或外延感到困惑，则应将其替换为更常见的术语。请记住，使用文档的读者可能并非以英语为第一语言，因此，您应尽力确保文档尽可能易于理解。
拉丁语缩写。避免使用缩写。例如 (for example), et al. (and others), etc (and so on) 和 i.e. (that is) 应始终使用英语对等词。
7. 元数据和标记审阅
LDP 使用一系列脚本将文档转换为其发布格式。为了使这些脚本工作，文档必须使用有效的标记并包含特定的元数据。元数据是关于文档的信息，包括作者信息、版权、许可证和文档的修订历史。
目前，元数据和标记审阅将由一位审阅协调员进行，并将是新文档的三次审阅中的最后一次。成功完成元数据和标记审阅后，审阅协调员将文档的版本号更新为 1.0，并将文档提交以在文档集中发布。
7.1. 必需的标记
提交给 TLDP 文档存储库的文档必须验证为以下格式之一
DocBook XML 版本 4.2（首选）、4.1.2
DocBook SGML 版本 4.2、4.1 或 3.x
LinuxDoc SGML
 | 不要求作者以 DocBook 格式提交文档 |
|---|---|
不要求作者以必需的标记语言之一提交其初始文档。将分配一名志愿者来转换任何未以有效标记提交的文档。作者必须以必需的格式之一维护其文档。当然，可以为作者提供帮助。《Linux 文档项目》的主要目标是提供高质量的文档，而不是强迫作者学习标记语言。 |
7.2. 必需的元数据
以下元素都是必需的
articleinfo 或 bookinfo。如果您正在编写较短的指南（这将是大多数文档），您将需要使用articleinfo，如果您正在编写较长的指南，您将需要使用bookinfo.
title。每个文档都必须包含一个简短的描述性标题。它应该具有合理的唯一性；检查文档集中的其他文档，以确保您的文档标题与所有其他文档都不同。虽然不是必需的，但大多数 “指南” 文档都在标题中包含单词 “指南”。
abstract。您的文档的简短描述必须包含在abstract中。此描述通常为一到两个句子的长度。
author。每个文档都必须有作者。如果有多个作者，您可以使用authorgroup。如果文档是由没有个人作者的组织准备的，请使用authorcorp代替。
editor。每个新文档都必须经过审阅过程，并列出技术、语言和元数据/标记审阅编辑。在某些情况下，两次审阅可能由同一个人进行。应包括编辑的姓名以及进行审阅的版本。有关此标记的更多信息，请阅读 作者指南 的 元数据标记 中的注释。
pubdate。文档的发布日期。日期应采用 ISO 标准 YYYY-MM-DD。
copyright。作者将始终保留他们提交给 LDP 的任何文档的版权。虽然不是必需的，但可以包含版权声明。但是，始终需要许可证。
修订历史 (revhistory)。文档中应包含修订摘要。有关其标记的更多信息，请阅读 作者指南 的 元数据标记 中的注释。
文档的初始版本应标记为版本 1.0。后续更新应适当增加版本号。首选格式为 Major.Minor.Bugfix，其中每个部分都是一个整数。一些作者使用 Alan Cox 风格的版本（例如 1.4pre-3），一些作者包含其他信息（例如 1.3beta）。这是可以接受的，但不鼓励这样做。最重要的是我们有一个版本号，以便我们知道我们正在处理哪个版本！文档经过审阅后，应根据引入的更改量增加次版本号或错误修复版本号。
许可证和法律声明。需要许可证。LDP 目前接受在 GFDL、Creative Commons License 和 LDP License 下获得许可的文档。如果您使用的许可证未列出，则需要我们的志愿者对其进行审阅，然后才能接受该文档。需要许可证的全文。链接是不够的。您可能希望将免责声明作为法律声明的一部分。标准免责声明可从 作者指南 中获得。
email。LDP 必须能够通过电子邮件联系任何文档的作者。电子邮件地址应包含在author标签中，但可以作为注释包含在 DocBook 源代码中。没有电子邮件地址的文档将不被文档集接受。如果 LDP 无法联系到作者，则文档可能会从文档集中删除。
致谢和其他鸣谢。很少有文档（如果有的话）仅由一个人编写。感谢那些在文档的写作、研究、测试或审阅方面帮助过您的人是一种良好的形式。如果有人添加了标记，或者将您的文档翻译成另一种语言，也应给予他们鸣谢。
8. 报告您的结果
完成文档审阅后，您应将更新的文件和您的结果发送回审阅协调员 [2] ，并告知工作组您已完成审阅。您的发现摘要应包含在电子邮件正文中。如果审阅者有权访问 CVS，并且获得作者的许可可以直接提交更改，则审阅者可以仅向审阅协调员发送一份调查结果摘要以及文档已在 CVS 中更新的注释的电子邮件。
如果您对文档进行了任何修改，请将您的更新发送给作者或维护者，以及 LDP 提交列表，该列表位于 submit@en.tldp.org。主题行应为文档的标题。在您的电子邮件正文中，请包含一条注释，内容大致为 “我是 LDP 的审阅者，并且代表作者提交本文档的更新副本。”
| 更新不应发送到讨论列表。 |
A. GNU 自由文档许可证
A.1. 0. 前言
本许可证的目的是使手册、教科书或其他书面文档在自由的意义上是“自由的”：确保每个人都拥有有效的自由来复制和再分发它，无论是否进行修改，无论是商业用途还是非商业用途。其次，本许可证为作者和出版商保留了一种方式来获得其作品的功劳，同时不被视为对他人所做的修改负责。
本许可证是一种“著作权保留”，这意味着文档的衍生作品本身必须在相同的意义上是自由的。它补充了GNU通用公共许可证，后者是为自由软件设计的著作权保留许可证。
我们设计本许可证是为了将其用于自由软件的手册，因为自由软件需要自由文档：自由程序应该附带提供与软件相同自由的手册。但是本许可证不限于软件手册；它可以用于任何文本作品，无论主题 matter 或是否以印刷书籍的形式出版。我们主要推荐本许可证用于以指导或参考为目的的作品。
A.2. 1. 适用性和定义
本许可证适用于任何手册或其他包含版权持有者声明可以根据本许可证条款分发的作品。“文档”，以下是指任何此类手册或作品。任何公众成员都是被许可人，并被称为“您”。
文档的“修改版本”是指包含文档或其一部分的任何作品，无论是逐字复制，还是经过修改和/或翻译成另一种语言。
“次要章节”是指文档的命名附录或前言部分，专门处理文档的出版商或作者与文档的整体主题（或相关事项）的关系，并且不包含任何可以直接归入该整体主题的内容。（例如，如果文档部分是数学教科书，则次要章节不得解释任何数学。）这种关系可能是与主题或相关事项的历史联系，或者是关于它们的法律、商业、哲学、伦理或政治立场。
“不变章节”是某些次要章节，其标题在声明文档根据本许可证发布的通知中被指定为不变章节的标题。
“封面文本”是在声明文档根据本许可证发布的通知中被列为封面文本或封底文本的某些简短文本段落。
文档的“透明”副本是指机器可读的副本，以通用公众可用的格式规范表示，其内容可以使用通用文本编辑器（对于像素组成的图像，可以使用通用绘画程序；对于绘图，可以使用一些广泛可用的绘图编辑器）直接且直接地查看和编辑，并且适用于输入到文本格式化程序或自动翻译成各种适用于输入到文本格式化程序的格式。以其他透明文件格式制作的副本，其标记旨在阻止或劝阻读者随后进行修改，则不是透明的。不“透明”的副本称为“不透明”。
透明副本的合适格式示例包括不带标记的纯ASCII、Texinfo输入格式、LaTeX输入格式、使用公开可用的DTD的SGML或XML，以及为人工修改设计的符合标准的简单HTML。不透明格式包括PostScript、PDF、专有格式（只能由专有文字处理器读取和编辑）、DTD和/或处理工具通常不可用的SGML或XML，以及某些文字处理器仅为输出目的而生成的机器生成的HTML。
“标题页”对于印刷书籍，是指标题页本身，以及为清晰地容纳本许可证要求在标题页中出现的材料所需的后续页面。对于没有标题页格式的作品，“标题页”是指最突出的作品标题附近的文本，位于正文文本的开头之前。
A.3. 2. 逐字复制
您可以在任何媒介中复制和分发文档，无论是商业用途还是非商业用途，前提是本许可证、版权声明以及声明本许可证适用于文档的许可证声明在所有副本中都得到复制，并且您不得在本许可证的条款之外添加任何其他条件。您不得使用技术措施来阻碍或控制您制作或分发的副本的阅读或进一步复制。但是，您可以接受报酬以换取副本。如果您分发足够大量的副本，您还必须遵守第3节中的条件。
您也可以在上述相同条件下借出副本，并且您可以公开展示副本。
A.4. 3. 大量复制
如果您出版超过100份文档的印刷副本，并且文档的许可证声明要求封面文本，则您必须将副本装在封面上，封面上清晰易读地带有所有这些封面文本：封面文本在封面上，封底文本在封底上。两个封面还必须清晰易读地标明您是这些副本的出版商。封面必须以相同突出且可见的方式呈现完整标题的所有单词。您可以在封面上添加其他材料。只要封面保留文档的标题并满足这些条件，对封面的更改的复制可以被视为其他方面的逐字复制。
如果任一封面的所需文本量太大而无法清晰地容纳，您应该将列出的第一个文本（尽可能多地容纳）放在实际封面上，并将其余部分延续到相邻页面上。
如果您出版或分发超过100份文档的不透明副本，您必须在每个不透明副本中包含机器可读的透明副本，或者在每个不透明副本中或随附声明一个公众可访问的计算机网络位置，其中包含文档的完整透明副本，不包含附加材料，普通网络用户可以使用公共标准网络协议免费匿名下载。如果您使用后一种选项，则在您开始大量分发不透明副本时，您必须采取合理谨慎的步骤，以确保此透明副本在所述位置保持可访问，直到您向公众分发该版本的最后一个不透明副本（直接或通过您的代理商或零售商）至少一年后。
建议但不要求您在重新分发大量副本之前与文档的作者联系，以便他们有机会向您提供文档的更新版本。
A.5. 4. 修改
您可以根据上述第2节和第3节的条件复制和分发修改版本的文档，前提是您完全在本许可证下发布修改版本，修改版本扮演文档的角色，从而将修改版本的发行和修改许可给拥有其副本的任何人。此外，您必须在修改版本中执行以下操作：
D. 保留文档的所有版权声明。
E. 在其他版权声明旁边为您的修改添加适当的版权声明。
F. 在版权声明之后立即包含一份许可证声明，允许公众根据本许可证的条款使用修改版本，格式如下文附录所示。
H. 包含本许可证的未修改副本。
K. 在任何标题为“致谢”或“献词”的章节中，保留该章节的标题，并在该章节中保留每个贡献者致谢和/或献词的所有实质内容和语气。
M. 删除任何标题为“背书”的章节。此类章节不得包含在修改版本中。
N. 不要将任何现有章节重新命名为“背书”或与任何不变章节的标题冲突。
如果修改版本包含符合次要章节条件的新前言部分或附录，并且不包含从文档复制的材料，您可以选择将部分或全部这些章节指定为不变的。为此，请将它们的标题添加到修改版本的许可证声明中的不变章节列表中。这些标题必须与任何其他章节标题不同。
您可以添加一个标题为“背书”的章节，前提是它仅包含各方对您的修改版本的背书——例如，同行评审声明或文本已被某个组织批准为标准的权威定义。
您可以添加最多五个单词的段落作为封面文本，以及最多25个单词的段落作为封底文本，添加到修改版本中的封面文本列表的末尾。任何一个实体（或通过其安排）只能添加一个封面文本段落和一个封底文本段落。如果文档已经包含同一封面的封面文本，该文本先前由您或您代表的同一实体安排添加，则您不得添加另一个；但是，您可以替换旧的文本，但需获得添加旧文本的先前出版商的明确许可。
A.6. 5. 合并文档
您可以将文档与根据本许可证发布的其他文档合并，根据上述第4节中针对修改版本的条款，前提是您在组合中包含所有原始文档的所有不变章节（未修改），并在其许可证声明中将它们全部列为组合作品的不变章节。
组合作品只需要包含本许可证的一个副本，并且多个相同不变章节可以用单个副本替换。如果存在多个名称相同但内容不同的不变章节，请通过在其末尾添加括号，注明该章节的原始作者或出版商的姓名（如果已知），否则添加唯一编号，使每个此类章节的标题唯一。对组合作品的许可证声明中的不变章节列表中的章节标题进行相同的调整。
在组合中，您必须合并各个原始文档中标题为“历史记录”的任何章节，形成一个标题为“历史记录”的章节；同样合并任何标题为“致谢”的章节，以及任何标题为“献词”的章节。您必须删除所有标题为“背书”的章节。
A.7. 6. 文档集合
您可以创建一个集合，其中包含文档和根据本许可证发布的其他文档，并将各个文档中的本许可证的单独副本替换为集合中包含的单个副本，前提是您在所有其他方面都遵循本许可证关于每个文档的逐字复制的规则。
您可以从这样的集合中提取单个文档，并根据本许可证单独分发它，前提是您在提取的文档中插入本许可证的副本，并在关于该文档的逐字复制的所有其他方面都遵循本许可证。
A.8. 7. 与独立作品的聚合
在存储或分发介质的卷中或卷上，将文档或其衍生作品与其他单独且独立的文档或作品汇编在一起，作为一个整体不被视为文档的修改版本，前提是不对该汇编声明汇编版权。这种汇编称为“聚合”，并且本许可证不适用于与文档这样汇编在一起的其他独立作品，因为它们是这样汇编在一起的，如果它们本身不是文档的衍生作品。如果第3节的封面文本要求适用于这些文档副本，那么如果文档小于整个聚合的四分之一，则文档的封面文本可以放在仅围绕聚合内的文档的封面上。否则，它们必须出现在围绕整个聚合的封面上。
A.9. 8. 翻译
翻译被认为是一种修改，因此您可以根据第4节的条款分发文档的翻译版本。将不变章节替换为翻译版本需要其版权持有者的特别许可，但您可以除了包含这些不变章节的原始版本外，还包含部分或全部不变章节的翻译版本。您可以包含本许可证的翻译版本，前提是您也包含本许可证的原始英文版本。如果本许可证的翻译版本与原始英文版本之间存在分歧，则以原始英文版本为准。
A.10. 9. 终止
除非本许可证明确规定，否则您不得复制、修改、再许可或分发文档。任何其他复制、修改、再许可或分发文档的企图均无效，并将自动终止您在本许可证下的权利。但是，根据本许可证从您处收到副本或权利的各方，只要这些各方保持完全合规，其许可证就不会终止。
A.11. 10. 本许可证的未来修订
自由软件基金会可能会不时发布GNU自由文档许可证的新修订版本。这些新版本在精神上与当前版本相似，但在细节上可能会有所不同，以解决新的问题或疑虑。请参阅https://gnu.ac.cn/copyleft/。
许可证的每个版本都给出了一个可区分的版本号。如果文档指定本许可证的特定编号版本“或任何更高版本”适用于它，您可以选择遵循该指定版本或自由软件基金会已发布的任何更高版本（非草案）的条款和条件。如果文档未指定本许可证的版本号，您可以选择自由软件基金会曾经发布的任何版本（非草案）。
A.12. 附录
要在您编写的文档中使用本许可证，请在文档中包含本许可证的副本，并将以下版权和许可证声明放在标题页之后：
版权所有 © 年份 您的姓名。
根据自由软件基金会发布的GNU自由文档许可证 1.1 版或任何更高版本的条款，授予复制、分发和/或修改本文档的许可；不变章节为 列出其标题，封面文本为 列出，封底文本为 列出。许可证的副本包含在标题为“GNU自由文档许可证”的章节中。
如果您没有不变章节，请写“没有不变章节”，而不是说明哪些是不变的。如果您没有封面文本，请写“没有封面文本”，而不是“封面文本为 列出”；封底文本也是如此。
如果您的文档包含重要的程序代码示例，我们建议根据您选择的自由软件许可证（例如GNU通用公共许可证）并行发布这些示例，以允许在自由软件中使用它们。