通用准则

除了行为准则之外，每个论坛都有其自身的特定准则，总结在以下子章节中。

论坛

特定于 Arch 论坛的准则。

如何发帖

选择清晰、信息丰富的主题。这更可能引起对特定主题有经验的用户的回应。它还使主题易于参考，并方便未来遇到类似问题的用户在论坛搜索中找到。此外，避免使用诸如 [求助！]、[紧急] 等无关短语。
真诚地努力使用谦逊和恰当的语言和语法，这表明对社区的尊重，肯定会受到赞赏，并且很可能引起积极的回应。避免使用所谓的“文本语言”、“网络语言”、“leet 语言”以及所有其他形式的网络俚语。
提问时，请提供尽可能多的信息，包括错误消息、终端输出、日志、您之前尝试过的操作、您尝试过的文档和搜索以及相关的配置文件。
每个主题一个帖子。在技术问题子论坛中通常不鼓励长篇帖子。
仅在一个子论坛中发布您的问题；选择最相关的，并在那里发布。
不要发布教程或“操作指南”：文档应放在 Wiki 中，以便维护。
在回复现有帖子时，始终阅读原始帖子并尝试关注原始主题。
最后，当找到解决方案时，通过编辑第一个帖子并在“主题”字段的标题前添加标签 [已解决] 来将您的帖子标记为已解决。
请注意，您应该避免使用 [已关闭]，它实际上是由系统用来标记不再允许新帖子的帖子。
如果帖子标记为 [已解决]，请不要回复说“我遇到了类似的问题……”；开始一个新帖子，并在相关时链接到 [已解决] 的帖子。

粘贴图片和代码

粘贴控制台代码段时，请使用 [code] 标签。发布大量代码时，请使用粘贴箱客户端。不要使用 pastebin.com——它对某些用户被阻止，并且有令人讨厌的问题的历史记录（JavaScript、广告、格式不佳等）。对于非英语区域设置用户：在发布的命令前加上 LC_ALL=C.UTF-8，以便输出为英语。不要发布全屏图片；请改用图片链接，可以选择带有缩略图。任何尺寸大于 250×250 像素或大小超过 50 KiB 的图片都将被删除。不要发布文本输出的屏幕截图；发布实际文本。

生活是双向的

一个简单但深刻且不可否认的真理。确保您的帖子包含其他人会觉得有用的详细信息和信息。与社区分享您的发现。也分享您的失败。在您的帖子中发布类似于“没事了，我修复了。”的内容，或者出于类似原因删除您自己的帖子，不仅对社区自私且毫无用处，而且完全浪费资源和每个人的时间。此外，在这里不受欢迎的是要求帮助或表现出粗鲁的不耐烦。Arch 由志愿者社区提供。强烈鼓励 Arch 用户进行研究、努力、在帖子中回复、帮助他人、参与并为社区做出贡献。

不要成为“帮助吸血鬼”。

产品推荐请求

不鼓励寻求有关计算机产品推荐建议的帖子。此类主题，就像它们讨论的技术一样，很快就会过时，并且不太可能为更广泛的社区提供任何持久的利益。您应该能够进行自己的研究并就哪种产品最适合您的个人需求得出自己的结论。

旧帖子/“坟贴回复”

尽您所能保持论坛整洁。由于 Wiki 是 Arch 文档的所在地，因此通常不鼓励在技术问题子论坛中回复旧帖子（“坟贴回复”），因为它可能会产生脱节的“僵尸”信息；过时的帖子包含由于 Arch 的滚动更新性质而不再相关的数据，以及反映当前情况的较新帖子。

经验法则:

如果您有问题，请开始一个新帖子，并在相关时链接到旧帖子。您也可以举报旧帖子，以便工作人员可以将其关闭。
如果您有要添加的内容，并且判断您的信息相关，但更及时，请开始一个新帖子，并在需要时链接到旧帖子，但避免重复发布 Arch Wiki 中已包含的信息，从而重复劳动。
如果您有版本无关或相应的解决方案，如果帖子不超过一两年，则坟贴回复可能是合适的。

禁止刷帖/空帖

刷帖最好被描述为发布空洞且毫无价值的消息。这是不能容忍的。人们可能有两个理由这样做：毫无意义地增加他们的帖子计数，或者像投票一样支持一个想法。刷帖的示例包括但不限于回复“+1”、“lol”、“我也是”、“我同意”或“:)”。

在发布或回复消息时，请确保您有话要说。这些空洞的帖子会使帖子和讨论变得混乱，使“显示新帖子”功能失效，并浪费带宽和服务器空间。

退化为一系列“+1/-1”或“我也是/我同意/我不同意”的帖子将被锁定。个人刷帖也可能被删除。

顶帖

不允许发布单字或无用消息（顶帖）以吸引对您帖子的注意。进行您自己的研究，继续进行故障排除，发布结果，并对社区保持耐心。如果有人正在阅读您的帖子但没有回答或提供帮助，您可以尝试提供更多详细信息，或要求指明正确的方向。通常，帖子无人回复的原因很大程度上是由于原始帖子本身的详细信息稀少，或者 Wiki、论坛或网络上明显有解决方案，以及社区不愿意指出显而易见的内容。

交叉发帖

交叉发帖是在不同的子论坛中多次发布相同的问题（例如，同时发布在新手区和安装区），或者在相同或不同的子论坛中发布问题略有不同的变体。这是对资源的浪费，是不允许的。任何交叉发布的帖子都将被立即锁定并标记为删除。

主题劫持

主题劫持是指回复现有帖子，但主题不同。通常不鼓励这样做。如果您遇到的问题与现有帖子问题相关但明显不同，则最好开始一个新帖子。也不鼓励用离题讨论来劫持严肃帖子的帖子。

垃圾箱政策（标记为删除）

由于已在论坛或 Wiki 上记录或与 Arch Way 不一致而被锁定/关闭的帖子将被移动到垃圾/钓鱼箱。五天后，该帖子将有资格由工作人员酌情删除。负责的版主将清楚地将帖子标记为“已放入垃圾箱”或“待删除”。

邮件列表

邮件列表的准则。另请参阅邮件列表发帖风格。

顶部发帖

永远没有理由进行顶部发帖。不要这样做。

引用

仅引用之前电子邮件中的必要元素（也称为交错引用）。批量引用会迅速膨胀帖子，降低可读性，同时增加整个列表的认知负荷。修剪所有冗余材料，仅回复相关的引用材料。

纯文本

纯文本是 Unix 和电子邮件标准。HTML 是不必要的，对于使用命令行客户端的人来说，是不受欢迎的。保持您的行长度合理：72 个字符被认为是默认的换行长度。

https://useplaintext.email/ 提供了配置电子邮件客户端以使用纯文本的说明。

回复到邮件列表

在回复邮件列表帖子时，请确保回复到邮件列表，而不是原始电子邮件的作者。大多数电子邮件客户端都应在回复选项中提供“回复到邮件列表”功能。如果没有，请在收件人字段中手动输入邮件列表电子邮件地址。

对于不需要订阅的邮件列表，例如 arch-mirrors-announce 和 aur-requests，请使用回复所有人，并确保邮件列表在收件人中。

AUR

Arch 用户仓库的准则可以在AUR 提交准则中找到。

IRC

所有 Arch IRC 频道都在 Libera Chat IRC 网络上。Libera Chat 上的用户必须遵守网络政策和 Libera Chat 频道准则。

#archlinux 频道的官方语言是英语。如果您需要其他语言的帮助，请搜索国际 Arch 频道。

#archlinux 的主要主题是关于 Arch Linux 的支持和讨论。允许关于软件和硬件的常规对话，只要它不干扰主要讨论主题。如果要求您将某些内容转移到另一个频道或私人消息，您应该这样做。
定期使用 /topic 阅读频道主题。它通常包含重要信息。
只有一个官方频道机器人：phrik。不要垃圾邮件机器人命令，并将您的使用限制在有帮助的事情上。如果您想将您自己的机器人带入任何 Arch Linux 频道，请事先询问操作员。
未经许可，请勿将频道桥接到任何其他网络或媒介。
未经所有参与者许可，请勿在公共场合发布日志。
不要用文本淹没频道。这包括 ASCII 艺术、机器人命令和错误日志。
- 使用粘贴箱分享超过三行的内容。program &> program-output.txt 与粘贴箱客户端结合使用可以简化此步骤。
- 如果您想尝试机器人命令或浏览帮助功能，请在 /query 或 /msg 中执行此操作。示例：/query phrik help command。
不允许在频道或私人消息中自动回复，但私人消息中的昵称高亮显示时的离开回复除外。
不要问是否有人活着或使用您的软件，只需陈述您的问题。
不要要求帮助；请求帮助。在重新提出问题之前耐心等待几分钟。大多数问题都由另一个用户（像您一样）回答。
当请求帮助时，如果有人要求您提供更多信息，请务必回复，如果您不知道答案，请说明。

Wiki

Wiki 的准则可以在ArchWiki:Contributing 中找到。

GitLab

软件包问题

在 archlinux/packaging/packages GitLab 命名空间中报告问题的准则可以在Bug 报告准则中找到。

软件包合并请求

以下准则适用于为 archlinux/packaging/packages GitLab 命名空间中的项目提交合并请求时。

从专用分支创建合并请求（不要使用默认分支 main）。这允许打包者重新定位您的更改。
进行描述性提交和详细的合并请求描述：保持这些内容清晰简洁有助于处理。
当提供提交以关闭工单时，请在提交消息的正文中使用有效的关键字之一。
在提交消息中引用（或关闭）工单或合并请求时，请使用工单或合并请求的完整 URL。
使 .SRCINFO 与您的更改保持同步（例如，也使用新的校验和、依赖项等更新 .SRCINFO）。
在提交和推送之前测试您的更改：验证软件包是否正确构建（在干净的 chroot 中），以及您要解决的问题是否已正确解决。
不要为琐碎的软件包更新创建合并请求：请改用 Arch 软件包网站上的标记软件包过期功能。仅仅增加 pkgver 通常不是阻止打包新版本的原因。
不要更改与发布相关的变量（pkgver、pkgrel、epoch）：合并请求应该是更改单元，而不是发布单元。发布更改的决定应留给软件包维护者。对此的例外情况是在旨在解决难以分类的软件包更新时打开的合并请求（例如，需要修补或更改构建/打包函数的更新，请参阅上一点）。