很欣赏 Ghostty 的这条问题反馈规则——普通用户只能在 Discussion 中发帖，当帖子讨论出清晰的问题和明确的可执行目标，项目维护者会将其转换为 issue。
https://github.com/ghostty-org/ghostty/issues/3558
这样做能解决一个热门开源项目的常见痛点——issues 往往充斥着低质量的提问和信息噪音，导致有价值的参考信息难以检索。让 Discussions 充当triage 的缓冲层，Issues 的管理也会变得更加容易。
但这样也可能会导致用户的反馈更难被关注到，能否得到解答，全靠维护者的对用户的责任心了。Discussions 可能会沦为一个大家都不想碰的 Backlog 池。
我一直觉得 Discussions 的曝光度不够，它不像 Issues 有显著的数量标识，容易被忽略；作为一个后期才添加的功能，其概念尚未完全普及。所以若想真正用好它，GitHub 应该增加一些功能，比如：
- 在导航条中为 Discussions 添加数量标识，可配置计算方式（如统计特定 tag 的数量）
- 在 repo 主页右侧展示近期或热门帖子，类似论坛板块的样式，以提升用户参与度
这件事本质上反映的是项目使用者与维护者之间永恒的矛盾。大部分使用者不可能像专业开发者那样写出逻辑清晰、信息完备的 issue；而维护者虽然有着完善项目的原始动力，但处理 issues 分类、bug 定位、沟通等繁琐事务却会带来沉重的心智负担。不过，正是这种矛盾迸发出了创新的火花，克服矛盾的过程也是一段宝贵的交流之旅。
所以做开源项目维护不仅仅是拿出了空闲的时间，更要耗费许多心力做自己舒适圈以外的事情。我们每一次顺畅地使用自己喜欢的工具，都应感谢他们的付出，向所有开源维护者致敬！虽然“只允许在 Discussions 中反馈”未必能解决所有问题，但这无疑是一个极具参考意义的尝试。
https://github.com/ghostty-org/ghostty/issues/3558
这样做能解决一个热门开源项目的常见痛点——issues 往往充斥着低质量的提问和信息噪音，导致有价值的参考信息难以检索。让 Discussions 充当triage 的缓冲层，Issues 的管理也会变得更加容易。
但这样也可能会导致用户的反馈更难被关注到，能否得到解答，全靠维护者的对用户的责任心了。Discussions 可能会沦为一个大家都不想碰的 Backlog 池。
我一直觉得 Discussions 的曝光度不够，它不像 Issues 有显著的数量标识，容易被忽略；作为一个后期才添加的功能，其概念尚未完全普及。所以若想真正用好它，GitHub 应该增加一些功能，比如：
- 在导航条中为 Discussions 添加数量标识，可配置计算方式（如统计特定 tag 的数量）
- 在 repo 主页右侧展示近期或热门帖子，类似论坛板块的样式，以提升用户参与度
这件事本质上反映的是项目使用者与维护者之间永恒的矛盾。大部分使用者不可能像专业开发者那样写出逻辑清晰、信息完备的 issue；而维护者虽然有着完善项目的原始动力，但处理 issues 分类、bug 定位、沟通等繁琐事务却会带来沉重的心智负担。不过，正是这种矛盾迸发出了创新的火花，克服矛盾的过程也是一段宝贵的交流之旅。
所以做开源项目维护不仅仅是拿出了空闲的时间，更要耗费许多心力做自己舒适圈以外的事情。我们每一次顺畅地使用自己喜欢的工具，都应感谢他们的付出，向所有开源维护者致敬！虽然“只允许在 Discussions 中反馈”未必能解决所有问题，但这无疑是一个极具参考意义的尝试。
