--- title: Freecodecamp Moderator Guidelines localeTitle: Freecodecamp版主指南 --- # 适度的支柱 最重要的是,请记住,您作为主持人的目的是为我们的社区服务: * 听 * 有帮助 * 不要滥用你的权力 # 调节Gitter 以下是主持人如何处理违反我们[的](https://www.freecodecamp.com/code-of-conduct) Gitter [行为准则的行为](https://www.freecodecamp.com/code-of-conduct) : 1. 主持人将立即禁止违规者。 2. 主持人然后会向他们发送此消息: > 这是一条标准消息,通知您我必须暂时禁止您进入freeCodeCamp的聊天室。 > > 我是代表我们的开源社区的主持人。我可以考虑取消你的禁令,但我需要你先做点什么。 > > 1.阅读我们[**`Code of Conduct`**]([https://www.freecodecamp.com/code-of-conduct) )。 > 2.请确认您已阅读。 > 3.向我解释为什么你认为我禁止了你。 3. 根据他们的回复,主持人将决定是否解雇违规的露营者。如果违规露营者之前没有被该主持人禁止,并且如果他们看起来很尊重和抱歉,那么主持人可以取消他们。作为一项政策问题,无论违规营员的行为多么糟糕,主持人在此过程中都会礼貌。 4. 主持人将键入事件的简短摘要以及他们如何在[管理室中](https://gitter.im/freeCodeCamp/admin)对其进行响应。以下是此类摘要的示例: > 我禁止了 @用户名发送垃圾邮件并向他们发送行为准则。他们说他们很抱歉,他们老实说没有意识到他们在做什么被认为是垃圾邮件。我取消了他们。 > > 我已经没有了 @用户名 。我向他们发送了行为准则。他们今天才意识到他们被禁止并为他们所做的事道歉。 > > 我已经禁止了 @用户名骚扰他们对我很讨厌。我建议我们联系Gitter全球禁令。 要禁止某人,请在聊天室中输入以下内容: > `/ban @username` 如果他们合作,你可以稍后解雇他们: > `/unban @username` 这仅适用于单个房间,因此您可能需要禁止它们多个地方。 如果露营者继续从一个房间跳到另一个房间造成问题,主持人可以在[管理室](https://gitter.im/freecodecamp/admin)请求全球禁令。 ### 删除Gitter消息 版主可以删除Gitter上的消息。他们应该只在三种非常具体的情况下运用这种能力: 1. 有人发布了色情或图形暴力图片。 2. 有人发布了一个恶意的链接或代码,可能会伤害点击它的其他营地人员。 3. 有人将聊天中的大量垃圾邮件充斥到极端程度(通常涉及机器人),以使聊天完全无法使用。 在所有其他情况下 - 即使违反行为准则的情况 - 主持人也不应删除该消息,因为这些是重要的历史记录。 ### 不要使用`@/all` 在任何情况下_`@/all`_不要使用_`@/all`_ 。该聊天室中的每个人都会收到通知。在某些情况下,成千上万的人。 相反,如果您希望人们看到通知,请使用标题文字大小。你可以在你的第一句话前放一个`#`来做到这一点。 ### 不要警告或威胁禁止 如果有人违反了行为准则,请不要警告他们或威胁要禁止他们。相反,悄悄地禁止他们,然后私下给他们发消息并按照上述协议进行。房间里没有其他人需要知道你禁止了这个人。 ### 不要吹嘘自己是主持人 不要把自己视为社区之上。你是社区。社区一直信任您,以帮助保护我们共享的罕见内容 - 这对新开发者来说是一个温馨的地方。 如果你吹嘘自己是一名主持人,人们可能会对你感到不安,就像人们可能会对警察感到不安一样,即使他们没有做错任何事。这只是人性。 ### 不要与其他主持人发生冲突 如果您不同意主持人的行为,请私下与他们交谈或在mod聊天中提出。永远不要覆盖禁令。相反,在模拟聊天中进行冷静的讨论,并说服主持人他们自己应该撤销禁令。 记住:我们都在同一个团队中。我们希望尊重主持人的角色,并提出统一的前沿。 # 审核GitHub 主持人是能够解决问题并接受或拒绝拉取请求的志愿者。 版主对GitHub有两个主要责任: 1. 评估和回答问题 2. QA'ing和合并拉请求 ### 评估和回应问题 freeCodeCamp是一个活跃的开源项目。我们每天都会收到几十个问题,所有问题都需要进行分类和标记。 有几个一般类别的问题: 1. **代码帮助请求** ,不适合问题。 如果问题显然是有人请求帮助,请粘贴以下消息,然后关闭该问题。 > 感谢您报告此问题。 > > 这是一条标准消息,通知您此问题似乎是请求帮助。请点击freeCodeCamp上挑战的**“帮助”**按钮,而不是在这里寻求帮助,这将带您到特定挑战的帮助聊天室。您还可以查看[**官方聊天室的完整列表**](https://forum.freecodecamp.com/t/free-code-camp-official-chat-rooms/19390) 。 > > 如果您认为我在解决此问题时出错了,请重新打开并添加进一步的说明。谢谢,快乐的编码。 2. **错误或澄清问题**如果可能,请**自行**确认错误。根据需要寻求其他详细信息,例如重现步骤。一旦问题被复制 - 或者至少被认为是合法的 - 标签已经`confirmed` 。然后: * 如果它是对现有挑战的简单更改,则标记为需要`help wanted`并且可选地, `first-timers-only`作为`first-timers-only` 。根据需要使用其他标签。 * 如果问题更重要,请标记为`bug` 。 * [标签使用指南](https://forum.freecodecamp.com/t/free-code-camp-issue-labels/19556) 如果对问题的正确行动方式存在任何歧义,请随时标记**`@freeCodeCamp/moderators`**以获取其他版主的意见。标志作为`Discussing` 。 3. **重复问题**如果问题与另一个报告的问题相同,则应优先考虑先前报告的问题。标记为`Duplicate` ,粘贴以下消息,将`#XXXXX`替换为问题编号,然后关闭该问题。 > 感谢您报告此问题。 > > 这是一条标准消息,通知您此问题似乎与问题#XXXXX非常相似,因此我将其作为副本关闭。 > > 如果您认为我在解决此问题时出错了,请重新打开并添加进一步的说明。谢谢,快乐的编码。 4. **在暂存中**已修复某些问题已在暂存中修复,但在同一主题上没有其他问题。粘贴以下消息,然后关闭该问题: > 感谢您报告此问题。 > > 这是一条标准消息,通知您生产中存在此问题,但已在暂存中修复。因此,我正在关闭这个问题。当暂存将再次推送到生产时,您的问题将得到解决。 > > 如果您认为我在解决此问题时出错了,请重新打开并添加进一步的说明。谢谢,快乐的编码。 5. **Bike Shedding** Bike Shedding是[帕金森琐碎法则的](https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)一个例子。有些问题根本不值得修复。如果您认为某个问题不值得,请将其标记为`bikeshedding` ,粘贴并填写以下消息,然后关闭该问题: > 感谢您报告此问题。 > > _简单解释为什么这是自行车,这是[帕金森琐碎法则的](https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)一种形式,所以我正在关闭它。_ > > 如果您认为我在解决此问题时出错了,请重新打开并添加进一步的说明。谢谢,快乐的编码。 ### 调节拉请求 Pull Requests(PR)是freeCodeCamp的贡献者如何向存储库提交更改以供考虑。这些PR的格式正确,并在合并之前进行全面的质量保证测试,这一点非常重要。 ### 拉取请求要求和格式 所有PR必须符合以下要求才能被接受: 1. 它必须至少引用一个未解决的问题,并且正文还应该为它所处理的每个问题编号包括`closes #XXXXX` (用问题编号替换`#XXXXX` ) 2. 它必须与**`staging`**分支相对 3. 它必须来自正确命名的非暂存分支,在用户的freeCodeCamp的个人分支上 4. 标题应描述所做的更改 5. 它的标题不应该有一个问题编号 6. 它的主体应该提供有关变化的详细信息以及测试级别(即未经测试,在本地测试) 7. 应将_相关_更改压缩为单个提交。但_相关或显着的_更改可能会有单独的提交。 8. 代码必须通过所有测试和linting 如果PR不满足这些要求中的一个或多个,请打开GitHub审核,指定尚未满足8个要求中的哪一个。新贡献者可能会被转介到[贡献者](https://gitter.im/freeCodeCamp/Contributors)聊天室。主持人可自行决定是否可以解决问题。 ### 质量保证(QA) 假设满足PR的基本要求,所有PR都应进行一定程度的QA测试。最基本的QA过程是在您的计算机上本地检查PR并测试更改的功能。 1. 确保您能够在本地重现该问题。 2. 验证PR实际上是否解决了问题。 3. 您可以使用**“LGTM”**回答问题,这意味着“看起来对我很好”。 4. 如果您对PR是否应该合并有任何疑问,请让第二个人QA,然后他们可以合并。 5. 如果已经有一个“LGTM”并且您也成功地对PR进行了QA,那么您应该合并它。 如果对功能有任何疑问,可以提及**`@freeCodeCamp/moderators`**以获得第二意见。 ### 特殊要求 更改网站底层功能或对网站的用户界面或用户体验进行重要更改的PR应由[@BerkeleyTrue](https://gitter.im/berkeleytrue)或[@QuincyLarson](https://gitter.im/quincylarson)批准。如果您有任何疑问,请在评论中标记它们和/或通过Gitter Chat吸引他们注意PR。 ### 主持人的其他规则 虽然您可以访问freeCodeCamp的存储库: * **你永远不应该将代码直接推送到freeCodeCamp存储库** 。所有代码都应该以repo的fork的pull请求的形式输入freeCodeCamp的代码库。 * 你永远不应该接受自己的PR。它们必须由另一位主持人进行QA编辑,就像任何其他PR一样。 # 主持论坛 审核论坛遵循与调节Gitter相同的原则。以下描述了轻微的变化,以解释与话语平台上的Gitter的差异。 论坛版主负责让我们的社区成为任何人学习和获得帮助的好地方。论坛版主将处理举报的帖子并处理垃圾邮件,偏离主题和其他不恰当的对话。 ### 删除论坛帖子 论坛版主可以删除用户的帖子。您只应对以下实例执行此操作: 1. 有人发布了色情或图形暴力图片。 2. 有人发布了一个恶意的链接或代码,可能会伤害点击它的其他营地人员。 3. 有人淹没了一个包含大量垃圾邮件的帖子。 ### 处理垃圾邮件 对于用户的第一个垃圾邮件,向他们发送解释问题的消息,并根据需要删除链接或帖子。在用户的个人资料中留言,说明您已采取的措施。如果问题仍然存在,请按照上述步骤操作。悄悄地阻止用户发布,然后使用行为准则发送警告。选中私信中的复选框,表明您的邮件是“正式警告”。 没有必要使用Gitter管理员空间来报告论坛上的事件。如果您有任何疑问,请在[员工](https://forum.freecodecamp.com/c/staff)论坛部分询问。 ### 处理偏离主题的对话 似乎位于错误位置的帖子或主题可以重新分类或重命名为适合的任何内容。 在特殊情况下,主持人可能适合将讨论分成多个线程。 同样,如果您有任何问题或疑问,请在“职员”类别中发布您的操作帖子,如果您希望他们审核您的审核操作,请标记其他主持人。 # 如何成为主持人 您是否一直在为我们的社区做出贡献,并希望成为主持人的额外权力/责任? 收集证据,证明您对GitHub问题的帮助,和/或帮助Gitter和我们的论坛上的露营者,以及在Gitter中的PM: * [@BerkeleyTrue](https://gitter.im/berkeleytrue) * [@CodeNonprofit](https://gitter.im/codenonprofit) * [@QuincyLarson](https://gitter.im/quincylarson) 其他要求: * 您必须在GitHub帐户上启用双因素身份验证。 * 您的GitHub个人资料至少应该有您的名字。 * 你的GitHub照片应该是你的脸。 如果您获得批准,我们会将您添加到我们的[主持人团队](https://github.com/orgs/freeCodeCamp/teams/moderators) 。 # 我们如何退休非活跃版主 请注意,我们会经常删除我们认为无效的问题mod。当我们这样做时,我们将发送以下消息: > 这是一条标准消息,通知您,由于您最近似乎不是主动版主,我们会将您从主持人团队中删除。我们非常感谢您过去的帮助。 > > 如果您认为我们错误地做了这件事,或者一旦您准备好回来并做出更多贡献,请回复此消息让我知道。 # 我们的贡献者房间如何运作 在[贡献者房间](https://gitter.im/freecodecamp/contributors)欢迎任何人。它是主持人和其他露营者的指定聊天室,他们以多种方式为我们的社区做出贡献,包括通过学习小组。 我们的假设是贡献者会在这个房间里读取任何用`@username`直接提及它们的内容,或者指向`@/all` 。其他一切都是可选的。但随意阅读任何人在那里发布和互动的内容。 # 如何成为这个论坛的主持人 如果您已经是主持人,您也可以在此论坛上申请主持人身份。在论坛上留言[@michaelhenderson](/users/michaelhenderson) ,他将在GitHub上验证您的主持人身份,然后在此授予您主持​​人身份。 # 与律师打交道 想要以某种方式与freeCodeCamp合作或联合品牌的组织可能会与您联系。一旦你意识到这就是他们所追求的,请停止与他们交谈并告诉他们直接与Quincy Larson对话。他每天都会得到这样的建议,并且最能判断这种关系对于我们的社区是否值得(并且很少)。 # 定义 > 本文档中的关键词“必须”,“必须”,“不需要”,“应该”,“不应该”,“推荐”,“可以”和“可选” [**应按RFC 2119中的**](https://www.ietf.org/rfc/rfc2119.txt)描述进行解释。