我的开源项目维护清单里，最重要的一栏叫「不打算修」
赤铜亭
·
先交代一个让我改观念的 issue：去年有位用户在我一个工具库里留言，「这个 2019 年就报过的边界 bug 什么时候修？」我翻了记录，那不是 bug，是我明确写着不支持的用法——在多线程里直接调一个标了「非线程安全」的函数。我客客气气回了链接，第二天对方回了一句让我记到今天的话：**「文档里写了，但我在 README 里没看到。」**
同一份规则，写在 CONTRIBUTING.md 里等于不存在，写在 README 里等于半个存在，只有出现在报错信息里才算真正存在。这是维护开源项目三年教我的第一课：边界不在你声明的地方，在对方撞上的地方。
后来我做了一件被朋友嘲笑的事：给项目建了一个「不打算修」清单，就放在 README 最显眼的位置。列三类东西：
1. **明确不支持的用法**——比如上面那个线程问题。原来它埋在文档第四页，现在提为第一屏。之前每个月有两三个相关 issue，列出来之后降到两三个月一个。
2. **不会做的功能**——总有人提「能不能加个 Web 界面」。以前我每个都认真回复「暂无计划」，半年后同样的提议换个人再来一遍。现在清单里一行字：Web 界面不在路线图，原因链接到讨论帖。提的人少了，提出来的人也更快接受。
3. **不承诺的兼容性**——哪个内部接口可能变，写清楚。升级踩坑的人少了一半怨气，因为他们是知情升级。
效果比预想的好，而且好得有点反直觉。我原本担心「不打算修」清单显得项目态度差，实际收到的 star 反而涨了——后来想明白了，**把边界画清楚本身就是一种可靠性**。用户不怕你功能少，怕的是不知道你哪里会塌。
当然也有代价。清单得维护：每半年过一遍，有些当初「不修」的东西，随着下游用户变多，会升格成「要修」。我学着把这条也写进去了——清单是快照，不是判决。
还有一个我不确定的事，说出来听听大家的做法：清单里第三类「不承诺的兼容性」，我至今没找到特别好的粒度。写太细，每次重构都要改一堆；写太粗，等于没写。有人用版本号分段承诺的，有人干脆全部标注 experimental。你们维护的项目里，边界声明一般写到多细？
帖子永久链接
