通用指南

除了行为准则外，每个论坛都有其特定的指南，总结在以下小节中。

论坛

Arch 论坛的特定指南。

如何发帖

选择清晰、内容丰富的主题。这更有可能引起对该特定主题有经验的用户的关注。这也能让未来的用户在遇到类似问题进行论坛搜索时，更容易参考和找到该话题。此外，请避免使用 [HELP!]、[URGENT] 等多余词汇。
真诚地努力使用平实且正确的语言和语法，是对社区尊重的表现，肯定会受到赞赏，并极有可能获得积极的回应。请不要使用所谓的“短信缩写 (textspeak)”、“网络俚语 (netspeak)”、“火星文 (leetspeak)”及所有其他形式的互联网黑话。
提问时，请提供尽可能详细的信息，包括错误信息、终端输出、日志、你之前尝试过的操作、你尝试过的文档查阅和搜索结果，以及相关的配置文件。
每个主题只讨论一个话题。在技术问题子论坛中通常不鼓励发布长贴。
只在一个子论坛发布你的问题；选择最相关的，然后在那里发帖。
不要发布教程或“如何做 (how to)”：文档属于 Wiki，在那里可以得到维护。
回复现有主题时，请始终阅读原帖，并尽量专注于原始话题。
最后，当找到解决方案时，请通过编辑首帖并在“主题 (Subject)”字段的标题开头添加标签 [SOLVED] 来将你的主题标记为已解决。
注意，你应该避免使用 [CLOSED]，这是系统用来标记不再允许新回复的主题的。
如果一个主题被标记为 [SOLVED]，请不要回复类似“我也有类似的问题……”；请启动一个新主题，并在相关时链接到那个 [SOLVED] 主题。

粘贴图片和代码

粘贴控制台片段时请使用 [code] 标签。发布大量代码时请使用 pastebin 客户端。不要使用 pastebin.com——它对某些用户被屏蔽，且有许多令人厌烦的问题（JavaScript、广告、格式差等）。对于非英语本地化用户：在发布的命令前加上 LC_ALL=C.UTF-8，这样输出将是英文。不要发布全屏图片；请使用图片链接，可选择带有缩略图。任何尺寸大于 250×250px 或大小超过 50 KiB 的图片都将被删除。不要发布文本输出的截图；请发布真实的文本。

生活是相互的

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

不要做一个“求助吸血鬼” (help vampire)。

产品推荐请求

不鼓励寻求电脑产品推荐建议的主题。这类话题就像它们讨论的技术一样，很快就会过时，不太可能为更广泛的社区提供持久的利益。你应该能够自行研究，并针对满足你个人需求的最佳产品得出自己的结论。

旧帖/“挖坟” (necro-bumping)

尽你所能保持论坛整洁。由于 Wiki 是 Arch 文档的归宿，在技术问题子论坛中通常不鼓励在旧帖中回复（“挖坟”），因为这可能会产生支离破碎的“僵尸”信息；即由于 Arch 的滚动特性而不再相关的过时帖子，与反映当前情况的较新帖子混杂在一起。

经验法则:

如果你有问题，请启动一个新主题，并在相关时链接到旧主题。你也可以举报旧主题，以便工作人员将其关闭。
如果你有东西要添加，并判断你的信息相关但更及时，请启动一个新主题并根据需要链接到旧主题，但要避免发布 Arch Wiki 中已包含的信息，以免做重复功。
如果你有一个与版本无关或相对应的解决方案，如果该主题的历史不超过一两年，那么“挖坟”可能是合适的。

禁止灌水/空帖

灌水 (Power-posting) 最贴切的描述是发布空洞且毫无价值的信息。这是不被容忍的。人们这样做可能有两点原因：毫无意义地增加发帖数，或者像投票一样支持某种想法。灌水的例子包括但不限于回复“+1”、“lol”、“我也是”、“我同意”或“:)”。

在发布或回复消息时，请确保你有话要说。这些空帖会弄乱主题和讨论，使“显示新贴”功能失效，并浪费带宽和服务器空间。

退化为一系列“+1/-1”或“我也是/我同意/我不同意”的主题将被锁定。个别灌水贴也可能被删除。

顶帖 (Bumping)

不允许发布单个词或无用消息（顶帖）来吸引对你主题的关注。请自行研究，继续排查故障，发布结果，并对社区保持耐心。如果人们阅读了你的主题却没有回答或提供帮助，你可以尝试提供更多细节，或请求指引正确的方向。通常，帖子无人回复的原因很大程度上是由于原帖本身细节匮乏，或者 Wiki、论坛或网上有显而易见的解决方案，而社区不愿指出显而易见的事情。

跨论坛发帖

跨论坛发帖是指在不同的子论坛中多次发布相同的问题（例如，同时在 Newbie Corner 和 Installation 中发帖），或在相同或不同的子论坛中发布该问题的略微变体。这是对资源的浪费，是不允许的。任何跨论坛发布的话题都将被立即锁定并标记为删除。

串改话题 (Thread hijacking)

串改话题是指在现有主题下回复一个不同的话题。这通常是不鼓励的。如果你的问题与已发布的现有问题相关但明显不同，最好开启一个新主题。同样不鼓励用无关讨论来干扰严肃主题的帖子。

回收站政策（标记为删除）

因板上或 Wiki 已有文档说明、或与 Arch Way 不一致而被锁定/关闭的主题将被移动到垃圾桶/喷子桶 (Dust/troll-bin)。五天后，该主题将由工作人员酌情删除。负责的版主会清楚地将该主题标记为“已丢弃 (Binned)”或“待删除”。

邮件列表

邮件列表指南。另见邮件列表发帖风格。

顶置回复 (Top posting)

顶置回复永远没有借口。不要这样做。

引用

仅引用前一封邮件中的必要元素（也称为交错引用）。大量引用会迅速使主题膨胀并降低可读性，同时增加整个列表的认知负担。删减所有多余内容，仅对相关的引用内容进行回复。

纯文本

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

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

回复到邮件列表

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

对于不需要订阅的邮件列表（如 arch-mirrors-announce 和 aur-requests），请使用“全部回复 (reply to all)”，并确保邮件列表在收件人之列。

AUR

Arch 用户软件仓库 (AUR) 的指南可以在 AUR 提交指南中找到。

IRC

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

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

#archlinux 的主要话题是对 Arch Linux 的支持和讨论。 只要不干扰讨论的主要话题，允许进行关于软件和硬件的一般性交谈。如果你被要求将讨论转移到另一个频道或私信，你应该照做。
经常使用 /topic 阅读频道主题。它通常包含重要信息。
只有一个官方频道机器人：phrik。不要滥用机器人命令，并将你的使用限制在有帮助的事情上。如果你想将自己的机器人带入任何 Arch Linux 频道，请在操作前询问频道管理员 (operators)。
未经许可，不要将频道桥接到任何其他网络或媒介。
未经所有参与者许可，不要公开日志。
不要用大量文本刷屏频道。这包括 ASCII 艺术、机器人命令和错误日志。
- 如果要分享超过三行的内容，请使用 paste bin。使用 program &> program-output.txt 配合 pastebin 客户端可以简化此步骤。
- 如果你想尝试机器人命令或浏览帮助功能，请在 /query 或 /msg 中进行。例如：/query phrik help command。
频道内或私信中的自动回复是不允许的，唯一的例外是在私信中因昵称被提及而触发的离开回复 (away response)。
不要询问是否有人在或者是否有人使用你的软件，直接陈述你的问题。
不要强求帮助；请礼貌请求。重述问题前请耐心等待几分钟。大多数问题是由像你一样的普通用户回答的。
寻求帮助时，请务必回复向你索取更多信息的人，如果你不知道答案，请说明。

Wiki

Wiki 的指南可以在 ArchWiki:Contributing 中找到。

GitLab

打包问题

在 archlinux/packaging/packages GitLab 命名空间中报告问题的指南可以在错误报告指南中找到。

打包合并请求

以下指南适用于向 archlinux/packaging/packages GitLab 命名空间中的项目提交合并请求 (merge request) 时。

从你的分叉 (fork) 项目中的专用分支创建一个合并请求（不要使用默认分支 main）。这以便于打包者后续变基 (rebase) 你的更改。
编写描述性的提交信息和详细的合并请求说明：保持清晰简洁有助于处理。
当提交的代码关闭了某个工单 (ticket) 时，请在提交信息的正文中使用其中一个有效的关键词。
在提交信息中引用（或关闭）工单或合并请求时，请使用该工单或合并请求的完整 URL。
保持 .SRCINFO 与你的更改同步（例如，同时更新 .SRCINFO 中的新校验和、依赖关系等）。
在提交和推送之前测试你的更改：验证软件包是否能够正确构建（在干净的 chroot 中），以及你处理的问题是否已正确解决。
不要为微小的软件包更新创建合并请求：请改用 Arch 软件包网站上的 Flag Package Out-of-Date（标记包已过时）功能。通常，单纯提升 pkgver 并不是阻碍新版本打包的原因。
不要更改与发布相关的变量 (pkgver, pkgrel, epoch)：合并请求应该是更改的单元，而不是发布的单元。发布更改的决定权应留在软件包维护者 (Package Maintainers) 手中。此条规则的例外是旨在解决难以分流 (difficult to triage) 的软件包更新的合并请求（例如，需要打补丁或更改构建/打包函数的更新，见前一点）。