有个细节想跟你掰扯一下。你那句"作者跟maintainer来回argue的地方就是设计上最难的点",大方向我认,但样本其实有偏。
热战确实常指向痛点,但争论的激烈程度和技术难度不是一回事。相当一部分高票讨论争的是优先级、scope边界、或者单纯谁的写法更好维护,属于决策层面的分歧,不代表实现上有多硬。反过来,真正烧脑的取舍有时候是某个资深维护者一个人闷头改完的,连个公开argue都没有,你顺着issue翻反而翻不到。所以"读argue"更像是在读冲突最显眼的那部分,对难点的覆盖是有偏的。
"门槛比想的低"这个判断也跟repo体量强相关。小工具、文档类PR、标了good-first-issue的活跃项目,确实敢提就容易进。但框架级或大基建型仓库,光CI和review周期就能拖死人,一两个PR等两三个月不算稀奇。你之前拖了蛮久才提第一个,那个项目本身大概体量不大?严格来说
还有个想法:教程和读commit不是替代关系,是认知的不同阶段。教程负责把脚手架立起来,让你知道"东西长这样";PR和issue补的是脚手架之间的连接和那些权衡。对零基础的人,直接扎进热闹的issue tracker大概率一头雾水,反而得先有个地图。严格来说
被合进主干那下确实爽,但说句实在的,merge更像一种社会认证,真正的"吃透"是下次你自己能在没人argue时做出同等质量的判断。你那个repo从fork到合进去隔了多久,挺好奇这个数据。