社区维护的功能区域
Multica 中哪些部分由社区贡献者维护、这对支持意味着什么，以及在这些区域遇到问题该怎么反馈。
Multica 的大部分功能由核心团队构建和支持。有少数功能区域由社区志愿者贡献，他们在合入后继续作为这些区域的社区维护者。这些区域会随每个版本发布，但不附带官方支持 SLA。
这一页是权威列表。它的作用有两个：让你在把工作流搭在某个区域上之前，先知道自己依赖的是什么；也让贡献这些工作的人被具名记录下来。
"社区维护"是什么意思
我们承诺什么。 该区域随每个版本发布。共享层重构时，核心团队负责让它继续编译、测试保持通过，并把该区域的问题路由给对应维护者。
我们无法承诺什么。 我们自己不日常使用这些平台，无法对着真实环境验证行为。需要真实平台权限才能定位的问题取决于志愿者的时间，因此没有响应时效保证。
区域如何退役。 如果某个区域坏在我们没有真实权限就修不了的地方，并且几个版本都没有修复出现，我们会把它标记为废弃，而不是让它悄悄坏着。这条规则既是对你的保护，也是对维护者的保护：志愿者哪天忙了或者离开了，不欠任何人一个修复。
功能区域
| 区域 | 代码 | 维护者 | 起始 | 状态 |
|---|---|---|---|---|
| 钉钉聊天集成 | server/internal/integrations/dingtalk | @yyclaw | 2026-08 | 活跃 |
| 企业微信聊天集成 | server/internal/integrations/wecom | @leroy-chen、@seacen | 2026-08 | 活跃 |
| Telegram 聊天集成 | server/internal/integrations/telegram | @leonzone | 2026-08 | 活跃 |
只有当某个区域的归属发生变化时，这个列表才会更新。未列出的部分都由核心团队维护。
在这些区域遇到问题怎么反馈
请提 GitHub issue，不要直接私信或 @ 维护者本人 —— 他们同意的是成为我们转过去的问题的第一接口，而不是任何人都可以呼叫的客服台。
Issue 表单里有一个 Area 字段。填上它，我们才能把反馈路由给对应的维护者，值得多点这一下。
成为维护者
如果你贡献了一个新的集成或者其他成规模的功能区域，我们会在合入前和你聊清楚这几件事：我们承诺什么、希望你承担什么，以及上面那条退役规则。拒绝完全没问题 —— 它影响的是这个区域怎么标注，而不是这份工作能不能合入。