组建 Discord 管理团队：在 2000 名成员时依然稳固的结构
大多数团队不是因为人不好而散掉，而是因为在招募、权限和不活跃方面缺少规则。一份来自实践的指南。
每个成长中的服务器都会到达这样一个时刻：一个人再也无法独自管理了。这时通常会发生什么：三个朋友因为经常在线而获得了管理权限。半年后，其中两个不再活跃，没人敢收回他们的身份组，而第三个已经精疲力竭。
这不是人员问题。这是缺少一套规则。
从权限开始，而不是从身份组开始
通常的顺序是反的。大多数人先创建听起来像等级的身份组，然后才去想它们应该被允许做什么。
把它倒过来。写下实际存在哪些任务：
- 需要有人删除垃圾信息、平息争吵
- 需要有人回答支持请求
- 需要有人决定谁加入团队
- 需要有人组织活动
然后再把任务打包成身份组。通常这样产生的身份组比你预想的少，而且每个都有明确的用途。
最低权限
一条能省去很多麻烦的规则：除非真的需要管理整个服务器，否则任何人都不应获得“管理员”权限。
对于日常管理，这些就足够了：
| 任务 | 所需权限 |
|---|---|
| 删除垃圾信息 | 管理消息 |
| 让某人冷静下来 | 禁言成员 |
| 移除某人 | 踢出成员 |
| 永久移除 | 封禁成员 |
就这些。管理频道、管理身份组和管理服务器属于领导层，而不属于日常管理。原因不是不信任，而是控制损失：如果某个账户被盗，正是这张清单决定了情况会有多糟。
招募需要流程
只要团队成员是凭直觉招募的，每一次拒绝都会变成私人恩怨。一个固定的流程能保护双方。
一个经过验证的流程：
- 通过表单申请，而不是私信。这样领导层的每个人看到的信息都一样。
- 事先公布最低要求。 例如：在服务器上待满 30 天、最低年龄、每周可投入的时间。
- 试用期。 四周的有限权限，然后再慎重做出决定。
- 拒绝就是附带理由的拒绝。 一句话就够了，但应该要有。
第 3 点最重要，也最常被省略。试用期给了你一个自然的退出口，谁都不会丢面子。
提前处理不活跃问题，而不是事后
这是最令人不快的部分，因此几乎每个人都会拖延。
一个三个月什么都没做的团队成员占着一个位置，还会打击那些认真干活的人的积极性。问题只在于：没有规则时，每一次关于此事的谈话都会让人觉得是人身攻击。
在你需要之前就把规则写下来。 例如：
每位团队成员每月至少处理 10 个支持案例。低于这个数的人会收到一条消息。下个月再次低于这个数的人交还身份组。
有两点让这条规则变得可以接受：
一个正式的请假方式。 假期、考试、生病。请了假的人在这段时间内不算不活跃。没有这条途径，规则就是不公平的，而且会被人绕过。
警告而不是移除。 第一次未达标是一条消息，而不是处罚。几乎每个人之后都会重新振作起来。
如果你想自动化：AlphaCloud 会通过支持记录或已处理的工单进行统计，并通过活跃度检查自行发送警告。已请假的成员会被跳过。
警告需要有效期
同样的逻辑也适用于团队内部。当一名团队成员犯了一次错并收到警告时，这个警告不应该永远存在。
一个永不过期的警告意味着，某个两年前失误过一次的人永远离被移除只有一步之遥。这既不公平，也没有用处。
设定一个期限，比如 90 天内没有新的警告，之后让警告等级失效。
让决定可见
两个值得设置的日志频道：
- 公开： 招募、晋升、离开。这是一种认可，顺便也回答了“到底谁是团队成员”这个问题。
- 内部： 警告、锁定、备注。仅限领导层。
这种分离正是关键所在。社区应该看到晋升，但不必看到关于它的每一次内部讨论。
一个自我维护的团队列表
一条列出所有团队成员的置顶消息，四周后就会过时。要么你每周手动维护，要么让它根据身份组自动生成。
后者是唯一能保持正确的方式。附带效果：当有人离开团队时，他们会自动从列表中消失，没有人需要记着这件事。
软件解决不了的部分
一个团队的成败取决于三件没有开关可以控制的事：
明确由谁做决定。 当两个管理员做出相互矛盾的决定时，问题几乎从来不在他们身上，而在于从来没有人说过，发生争议时谁说了算。
撑腰。 一个做出了不受欢迎但正确决定的管理员，如果随后被领导层公开纠正，下次就干脆不会再做决定了。
一条退路。 大多数人离开团队不是因为生气，而是因为生活发生了变化。如果退出意味着被当成叛徒，人们就不会退出，而只是变得不活跃。然后你又回到了开头的那个问题。