Repository navigation
从给 RisingWave 提 PR 说起，聊聊怎么快速切入一个复杂的开源项目 #296
Description
对于大部分项目来说，如果想做一点贡献的话，只要跑起来其实已经能找到能贡献的地方了。
引子
前阵子机缘巧合下接触到了 risingwave 在这之前我可以说是仅仅从几个在这工作的几个厉害的推友那里得知有这么一个用 Rust 写的流数据库，而流数据库是什么，到底什么原理，也仅仅是有所想象。既然是机缘巧合下了解到的，就试试去看看他的代码，去了解下它到底是怎么回事儿，顺便学点什么。
这里特别感谢下叉鸽。
正文
那么如何快速去切入一个项目呢？Cursor, copilot, marscode? No, 目前这种补全工具在做一个几千个人做过的 demo 里，是无敌的，但对了解一个大项目，甚至能给这个大项目提交一点代码修改一些 bug 的能力近乎于 0. （突然想到好久没有当时特别火的那个解决程序员问题的创业公司的信息了，留下了个 demo, 半年过去了）
既然这些不行，什么可以呢？根据我自己的经验步骤如下。
- GitHub Actions workflow 比文档要好用，对于一个 CI/CD 写的好的项目，我一般会直接点开
.github下面的workflow如果这个项目很成熟，里面大概率会包括，如何编译，编译需要的依赖是什么？如何测试，需要的版本，不同环境需要安装的不同的包，都会在这个 workflow 里。看里面的 workflow, 然后根据步骤，编译，跑一些简单的命令，项目就跑起来了。 - 去扫一眼 good first issue, 点开 issues -> tag 筛选 -> good first issue, 去找一个一般 type 为 bug 的，然后结合第一步跑起来的，去把这个 bug 复现，OK 如果能复现已经实现了 1/3 了。
- 去 PR 里看看，一般一个正在发展的项目会有很多活跃开发者提的 PR, 而提 PR 一般需要做一些本地测试或者写好 pr messaage, 在里面会有一些开发者习惯的命令，比如
./risedev c可以在本地试一下。 - OK 有了这个 ./risedev 跑一下，就大概知道了开发者们常用的命令，本地都实验一下，大致就知道开发流程了
- 语言是 Rust 我也不会啊？没啥问题啊，既然能跑起来试试呗，去网页搜索
debug rustOK 学习到了和 C 语言一样可以用 gdb 而且有 rust-binding 可以用 rust-gdb, 去项目目录看到，有一个.vscode文件夹里面有如何用 VSCode debug 他们用的是 lldb, 我习惯命令行，再搜索下 lldb 也有 binding -> rust-lldb - 能 debug 其实又完成 1/3 了，接上面的能复现的 issue -> 跑起来 -> 复现 -> ps aux| grep risingwave 去找到进程号，卧槽！这里好多进程号，两个方案，去按照文档 + issue 搜索去研究下大概应该哪个进程 or 一个一个实验。我都做了。明白了这个 bug 是在 front 进程 -> rust-lldb -p ${pid} 这个时候去研究下需要 break 的点，怎么研究呢？当然是看 log 啊！找到了 log(发现其中有个可以改进一点点的点）正好可以帮提个 PR, 找到 log 后大概率能拿到 backtrace 当然也可在 lldb 中用
bt拿到 backtrack 之后就可以去 break 你想 break 的点了（这里因为 Rust 我不太熟悉，项目也太大，lldb 略卡，我选择直接 break 行号b xxxxxxx.rs:41另一个 terminal 跑 sql 再去 lldb 里一步一步调试就好了。 - 调试的过程中一点一点学习相关的知识，这个时候无论是 google ChatGPT 还是其它的都会派上用场了，哪里不会问哪里。
- 最有效的可能是 issues 和 PR, 有时候有问题不解对于一个成熟的开源项目来说可以直接去 issues 里搜索相关的关键字，然后大概率有 PR 的双向链接，点进 PR 看代码更改的 diff 学习下前面的大哥是怎么做的，能帮忙更好的定位问题。
- 尝试解决问题。
- 解决不了其实无所谓，因为经过了以上的步骤其实对项目已经有一点点了解了，这就够了，能学到一些东西就更开心了。
Activity
Mellorsssss commentedon Oct 11, 2024
写的很好:)
yihong0618 commentedon Oct 11, 2024
谢谢～
whyiug commentedon Oct 11, 2024
最近给一个复杂又不熟悉的项目（大模型推理框架 vllm） 提 pr 差不多也是按照这个方法来的。（action, ci, issue, debug, 分步拆解问 gpt），很有收获。
我的 pr
zlog-in commentedon Oct 11, 2024
真棒，俺也想找个项目试试
yihong0618 commentedon Oct 11, 2024
来～
renjieliu commentedon Oct 11, 2024
确实是这样, 工作中理解现有项目的切入点也是接到ticket, 解决ticket. (尤其是有人在后面催着的时候...). 尝试解决问题的过程中, 会了解到业务, 代码的edge case... 光靠读是没有体会的, 上午看, 下午就忘了.
boholder commentedon Oct 12, 2024
（比较好奇yihong老师是怎么同时完成 跑步+带娃+工作+开源 的，相信yihong老师一定有高效的时间管理技巧。。
最近读《时间贫困》，有几个行为能通过增加自我效能感，缓解主观对时间的紧张感：运动、助人、感受自然。猜测yihong老师本人对时间也是不会感到紧张的
yihong0618 commentedon Oct 12, 2024
我很少做时间管理，不过有些事儿日常就习惯下来了。嗯嗯是的我对时间不怎么紧张哈哈。
Appointat commentedon Oct 18, 2024
牛，学到了。可以给我的开源生活提效🥰
skyloevil commentedon Apr 17, 2025
赞
otakutyrant commentedon May 16, 2025
测试这方面怎么说呢？我发现 stanza 这个项目跑测试太花时间了，平均二十分钟，也有一些错误和警告，我打算在提交 PR 前先本地测试好，结果修起来和跑测试都很辛苦。stanza 官方的 workflow 大概托管在斯坦福大学服务器上，毕竟要用 GPU。
Zhonghe-zhao commentedon Jun 26, 2025
太棒啦老师！帮助非常大
zerone0x commentedon Jun 27, 2025
厉害👍
yihong0618 commentedon Jun 27, 2025
这些 Actions 能跑，如果是内部的话我不太清楚
yihong0618 commentedon May 2, 2026
2026-05-02 补充：
已经完全变了，现在用任何 SOTA 的模型加上任何实现了 pi 的 agent 都可以给任何项目提 PR, 而且解决的比我这篇写的好的多，但是，那并不是你的能力，时代变了。