Trail of Bits publications 仓库贡献指南从读懂目录结构到提交第一个 PR【免费下载链接】publicationsPublications from Trail of Bits项目地址: https://gitcode.com/GitHub_Trending/pu/publicationspublications 是 Trail of Bits 的公开出版物归档仓库收录安全审查报告、会议演讲、论文与数据集。读完这篇 publications 贡献指南你可以独立走通完整闭环看懂仓库结构、在本地验证表格渲染、挑一个合适的任务并交出一个符合仓库规矩的第一个 PR。里程碑一 · 先看懂它这个仓库到底存了什么一句话定位这里没有代码只有一份 1300 多行的 README.md 当目录索引加上一堆 PDF 和幻灯片——你几乎所有的贡献都是放好文件 在表格里加一行。目录负责什么你碰它的频率reviews/数百份安全审查报告 PDF命名如2025-03-scroll-euclid-phase1-securityreview.pdf最常碰README.md唯一入口所有条目表格都在这份文件里最常碰presentations/每个演讲一个目录内含README.md 幻灯片 PDF常碰papers/、reports/、case-studies/论文、白皮书、客户案例偶尔workshops/、datasets/工作坊材料与公开数据集偶尔/ai_maturity_matrix.png?utm_sourcegitcode_repo_files)图presentations/下归档的演讲素材示例——你的任务就是让这类文件在 README 表格里有迹可循里程碑二 · 本地跑通没有构建脚本怎么算跑起来了环境要求git 和一个能预览 Markdown 的编辑器VS Code 自带。不需要安装任何依赖。git clone https://gitcode.com/GitHub_Trending/pu/publications克隆仓库到本地。cd publications git checkout -b add/my-first-review从 master 拉一个自己的分支。仓库规矩是所有修改走新分支 PR永不直接提交到 master。怎么确认环境搭好了两个成功信号在编辑器里打开README.md开 Markdown 预览表格应整齐渲染点一个 图标能跳到对应 PDF说明相对路径没断。终端里对任意一张审查表做列对齐检查例如 Ethereum/EVM 一节sed -n /^#### Ethereum\/EVM$/,/^####/p README.md | grep ^| | awk -F| {print NF} | sort -u它统计该节所有表格行的字段数输出应该只有一个数字——意味着每行列数一致。如果蹦出好几个数字说明这张表里混进了截断行你的眼睛已经能发现问题了这就是跑通。里程碑三 · 选任务第一个任务去哪里找任务来源就是仓库的 issues 和标签。这个仓库的典型任务长这样加一条新审查报告客户同意公开后把 PDF 放进reviews/在对应分类表格加一行归档一场演讲presentations/下建目录、写带 frontmatter 的README.md、在根表格加一行格式修复某行月份写成了 September、某行少一个竖线、条目排序乱了选题判断标准三条都满足再动手范围小改动不超过1 个文件 一两行表格需要新增整节的大任务留到后面描述清晰issue 里能直接拿到文件名、作者、日期、公告链接不用猜与现有结构耦合低不需要挪动章节顺序、不需要同步更新文件头部的目录动手前先确认这条记录是否真的该公开仓库里大量审查属于 confidentialissue 没明确说可公开就先别做问一句比返工便宜。里程碑四 · 开发与自检Markdown 表格有哪些暗规矩这个仓库的代码规范全写在 CLAUDE.md 里挑最容易踩的几条月份一律 3 字母缩写Jan–Dec禁止September也禁止 4 字母的Sept审查表固定 5 列每行必须恰好 6 个|缺数据的列用空单元格| |补齐不许截断Product 列只写干净的产品名不带 Security ReviewProtocol 这类后缀冗长名字要缩短文档图标有分工 评估报告、✅ 修复复审、 公证函、 威胁模型同一产品的多个文档挤在同一行图标之间不留空格演讲目录只以演讲标题命名不带会议名目录内必须有带 YAML frontmattertitle/date/authors/conference/resources的README.md各节内部按日期从新到旧排序改格式时永不顺手修改 URL 或文件路径避坑最危险的操作是顺手规范化——把相邻行的日期、空格也一起改掉diff 会突然变大。维护者要的是最小改动你的第一份 PR 尤其如此。提交前自检清单每行表格的|数量与表头一致空单元格是| |日期全是 3 字母月份小数写作0.2而不是.2新条目插在对应节的最前面最新的在最上且没有重复条目演讲目录的README.mdfrontmatter 字段齐全diff 里没有任何顺手修好的 URL、路径或相邻行里程碑五 · 交出去PR 写什么review 怎么接提交信息看 git log历史提交都是add report and update readme这种直白风格。沿用add:/fix:前缀即可例如git commit -m add: scroll euclid phase 2 security review entry一行说清加了什么、动了哪张表比长段落好使。PR 描述三句话就够改了什么哪个分类、哪个条目、依据issue 编号、怎么验证的例如已确认 Ethereum/EVM 表全部行字段数一致日期按从新到旧排列。review 应对维护者最常见的意见是格式问题。假设有人留言Product 列太长了参考 CLAUDE.md 里 Product Column Formatting 那段可以这样回收到我把Offchain Labs Custom Fee ERC-20 Bridge Upgrade and EIP-7702 Fixes缩成Offchain Custom Fee Bridge EIP-7702去掉冗余后缀马上提交。具体引用对方指出的规则 给出你的改法比回一个OK 已修改高效得多。下一步第一个 PR 不追求惊艳追求零返工挑一条加审查报告的 issue按里程碑四的清单过一遍交出去。仓库规矩在 CLAUDE.md条目格式对着 README.md 里同类表格抄任务去 issues 的 good first issue 标签下翻。你缺的不是技能是一次动手。【免费下载链接】publicationsPublications from Trail of Bits项目地址: https://gitcode.com/GitHub_Trending/pu/publications创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考