反馈渠道易于启动：添加一个电子邮件地址、启用 GitHub 议题（Issues），或链接一个表单。
困难的部分始于第一条消息到达之后。
如果没有明确的工作流程，维护者最终不得不检查多个相互隔离的收件箱。报告者不知道去哪里提问，私信无法被其他贡献者搜索到，而议题则处于模糊状态，直到每个人都假设其他人已经处理了它们。
解决方案并不是另一个通知目的地。而是一个小型的路由和分类系统，拥有一个可见的入口点、明确的责任归属以及有限的状态集。
本教程围绕 GitHub 构建该系统，但同样的模型也适用于 GitLab、工单跟踪器或共享支持队列。
从路由契约开始
在配置工具之前，先决定每种类型的消息应归入何处。
一个实用的路由表可能如下所示：
| 消息类型 | 目的地 | 可见性 |
|---|---|---|
| 可复现的错误 | GitHub 议题 | 公开 |
| 功能提议 | GitHub 议题或讨论 | 公开 |
| 使用问题 | GitHub 讨论 | 公开 |
| 安全漏洞 | 安全政策说明 | 私有 |
| 账户、账单或个人数据 | 联系渠道 | 私有 |
| 可转化为行动的一般反馈 | 联系渠道，经许可后提升为议题 | 首先私有 |
这种分离很重要。公开渠道使可重用的知识可被搜索，而私有渠道则为不应发布在议题中的信息提供了出口。
在 SUPPORT.md 中记录该契约：
# 支持
## 错误和功能请求
提交一个 GitHub 议题。请先搜索现有议题，并在报告错误时包含最小复现步骤。
## 问题
使用 GitHub 讨论来获取设置帮助和提出开放式问题。
## 私信
对于账户详情、个人信息或您不想公开发布的反馈，请使用我们的私密联系页面。
## 安全漏洞
不要公开提交议题。请遵循 SECURITY.md 中的说明。
## 审查频率
新的议题将在周二和周五进行审查。这是一个审查目标，而非保证的解决时间。
在 README 文件中链接此文件，以便贡献者无需通过浏览仓库来发现它。
## 帮助和反馈
- [报告错误](https://github.com/OWNER/REPOSITORY/issues/new/choose)
- [提出问题](https://github.com/OWNER/REPOSITORY/discussions)
- [发送私信](https://example.com/contact)
- [阅读支持政策](SUPPORT.md)
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
