为什么你的第一个 PR 应该从 SGLang 或 TileLang 开始

很多开发者对给开源项目提 PR 有畏难情绪，觉得非得是惊天动地的性能优化或者架构重构才拿得出手。其实，开源社区最欢迎的往往是那些“小而美”的修正。特别是像 SGLang 这样的大模型推理框架，或者 TileLang 这种算子优化 DSL，文档的滞后或者边缘场景的 Bug 修复，对新用户来说就是救命稻草。

与其在本地对着报错发呆，不如直接去上游修好它。今天咱们不聊虚的，直接模拟一个真实场景：你在跑 SGLang 的 ROCm 示例时，发现文档里的启动参数少了一个关键的环境变量，导致服务起不来。咱们就以此为例，走一遍从 Fork 到 Merge 的全流程。

动手前的准备：Fork 与环境搭建

首先，登录 GitHub，找到 SGLang 的官方仓库（假设是 sgl-project/sglang）。点击右上角的 Fork 按钮，把代码克隆到你自己的账号下。

git clone https://github.com/你的用户名/sglang.git
cd sglang

关键点来了：不要直接在 main 分支上改。养成好习惯，基于最新的 main 分支切一个新分支，名字要有语义，比如 fix/rocm-doc-env-var。

git checkout -b fix/rocm-doc-env-var

接下来是环境。ROCm 开发最忌讳污染系统环境，强烈建议用 Docker。如果你本地有 AMD 显卡，可以直接挂载；如果没有，至少要在容器里把 rocm-dev 包装好，确保能跑通 hipcc -v。

定位问题与本地验证

假设你发现 docs/rocm_quickstart.md 里漏写了 HSA_OVERRIDE_GFX_VERSION 这个变量，导致某些非官方支持的显卡（如 7900XTX）无法识别。

1. 复现：按照文档操作，确认报错。
2. 修复：在本地修改文档，或者如果是代码逻辑问题（比如 TileLang 的某个 kernel 在特定 block size 下报错），修改对应的 .py 或 .tl 文件。
3. 验证：这一步不能省。如果是文档修改，确保新指令在你的环境里能跑通；如果是代码修改，跑一下相关的单元测试。

比如修复 TileLang 的一个小逻辑：

# 修改前
block_size = 256 
# 修改后：适配 MI300X 的 Wavefront 特性
block_size = 256 if arch != 'gfx942' else 512 

改完后，本地跑一下简单的算子测试，确保没引入回归错误（Regression）。

提交规范：让维护者一眼看懂

很多新手的 PR 被拒，不是因为代码写得烂，而是因为描述不清。维护者每天要看几十个 PR，他们没时间猜你想干嘛。

使用 git commit 时，遵循社区通用的格式。SGLang 和 TileLang 通常遵循 Conventional Commits 规范。

git add .
git commit -m "docs(rocm): add HSA_OVERRIDE env for unsupported GPUs

- Update rocm_quickstart.md to include gfx version override
- Add troubleshooting section for 7900 series
- Fixes #1234"

注意细节：

• Type: 用 docs, fix, feat 明确改动类型。
• Scope: 标注 (rocm), (tilelang) 等范围。
• Body: 简单解释“为什么”这么改，而不仅仅是“改了啥”。
• 关联 Issue: 如果之前提过 Issue，务必在 commit message 里写上 Fixes #IssueID，这样合并后 GitHub 会自动关闭该 Issue。

发起 Pull Request 的艺术

推送到你的远程仓库：

git push origin fix/rocm-doc-env-var

然后去 GitHub 页面，你会看到一个绿色的 “Compare & pull request” 按钮。点击它，进入 PR 编辑页面。

PR 描述模板（建议收藏）：

## Description
本文档修复了 ROCm 快速开始指南中关于非官方显卡支持的配置遗漏。

## Motivation
在 RX 7900XTX 上按照原文档操作会报 `HSA agent not found` 错误，添加该环境变量可解决此问题，降低新手入门门槛。

## Test Plan
- [x] 本地 RX 7900XTX + ROCm 6.2 验证通过
- [ ] CI/CD 流水线检查（等待自动触发）

避坑指南：

1. 保持专注：一个 PR 只做一件事。别把文档修改和算子优化混在一个 PR 里，这会让 Review 变得极其困难。
2. 响应反馈：维护者可能会让你改代码风格或者补充测试。别觉得是刁难，这是开源协作的常态。直接在本地改完，git push 即可，PR 会自动更新，不需要关闭重提。
3. 礼貌沟通：技术讨论对事不对人。如果意见不合，提供数据或日志来支撑你的观点，而不是情绪化表达。

迈出第一步之后

当你看到 PR 状态变成 Merged，那种成就感是无可替代的。这不仅仅是给社区做了贡献，更是你技术履历上实实在在的一笔。

ROCm 的生态还在快速成长期，像 SGLang 的算子适配、TileLang 的 DSL 语法糖、LLaMA-Factory 的分布式训练支持，都有大量的优化空间。别被“大神”的光环吓退，从修复一个错别字、补充一行配置开始，你就是这个生态的建设者。

现在，打开你的终端，去 Fork 那个你一直想用的项目吧。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper