贡献指南 - OpenZeppelin 文档

贡献指南

欢迎来到 OpenZeppelin Monitor 项目！感谢你有兴趣参与贡献。本指南概述了为项目做贡献的要求和流程。

入门

OpenZeppelin Monitor 项目在 CONTRIBUTING.md 文件中提供了全面的贡献指南。本文档提供了关键要求的摘要，但要获得包括 GitHub 工作流程、标签指南和高级主题在内的完整详细信息，请参阅完整的 CONTRIBUTING.md 文件。

主要要求

贡献者许可协议 (CLA)

在贡献之前，你必须签署 CLA。 CLA 流程通过 GitHub 工作流程自动完成，该工作流程会相应地检查和标记 PR。

• 所有贡献者都必须完成 CLA 流程

• CLA 机器人将自动检查你的 PR 状态

• 没有签署 CLA 的 PR 无法合并

签名提交

所有提交都必须经过 GPG 签名，这是一项安全要求。

• 为你的提交配置 GPG 签名

• 未签名的提交将不被接受

• 这有助于确保代码的完整性和真实性

开发环境设置

先决条件

在贡献之前，请确保你已具备以下条件：

• Rust 2021 edition - 开发必需

• Git - 用于版本控制

• Python/pip - 用于 pre-commit 的Hook

初始设置

## 克隆并设置存储库
git clone https://github.com/openzeppelin/openzeppelin-monitor
cd openzeppelin-monitor

## 构建项目
cargo build

## 设置环境变量
cp .env.example .env

运行测试

## 全部测试
RUST_TEST_THREADS=1 cargo test

## 集成测试
RUST_TEST_THREADS=1 cargo test integration

## 基于属性的测试
RUST_TEST_THREADS=1 cargo test properties

开发工作流程

1. Pre-commit Hook

代码质量检查的必需项，包括 rustfmt、clippy 和提交消息验证。

• 安装并配置 pre-commit Hook

• 自动格式化和 linting 检查

• 提交消息格式验证

安装 Pre-commit Hook

安装并配置 pre-commit Hook以确保代码质量：

## 安装 pre-commit（如果喜欢全局安装，请使用 pipx）
pip install pre-commit

## 安装并配置 commit-msg、pre-commit 和 pre-push 的Hook
pre-commit install --install-hooks -t commit-msg -t pre-commit -t pre-push

pre-commit Hook将在每次提交和推送时自动运行，并检查： * 使用 rustfmt 进行代码格式化 * 使用 clippy 进行 Linting * 提交消息格式验证 * 其他代码质量检查

2. GitHub 工作流程

Fork 和克隆

1. 在 GitHub 上 Fork repository

2. 在本地 克隆你的 fork：

## 设置你的工作目录
export working_dir="${HOME}/repos"
export user=<your-github-username>

## 克隆你的 fork
mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/openzeppelin-monitor.git

## 添加 upstream remote
cd openzeppelin-monitor
git remote add upstream https://github.com/openzeppelin/openzeppelin-monitor.git
git remote set-url --push upstream no_push

分支管理

• 从最新的 main 分支创建 feature 分支

• 定期与 upstream 同步

• 使用描述性的分支名称

## 保持 main 更新
git fetch upstream
git checkout main
git rebase upstream/main

## 创建 feature 分支
git checkout -b feature/your-feature-name

## 保持分支更新
git fetch upstream
git rebase upstream/main

3. Pull Request 流程

创建 Pull Request

1. 将你的更改推送 到你的 fork:

git push -f origin feature/your-feature-name

2. 在 GitHub 上 创建 Pull Request

3. 添加适当的标签（请参阅下面的标签指南）

4. 包含对你的更改的清晰描述

PR 的最佳实践

• 编写清晰且有意义的提交消息

• 在 PR 正文中包含 fixes #123（而不是提交消息）以自动关闭问题

• 将大的更改分解为更小、更合乎逻辑的提交

• 确保所有测试通过

• 包括足够的信息以供审阅者参考

代码标准

Rust 标准

Rust API 指南：

• 使用 rustfmt 格式化代码

• 通过所有 clippy linting 检查

• 遵循 Rust 命名约定

## 格式化代码
cargo fmt

## 检查 linting
cargo clippy --all-targets --all-features

## 运行测试
RUST_TEST_THREADS=1 cargo test

测试要求

所有贡献都必须通过现有测试，并在适用时包含新测试：

• 为新功能编写单元测试

• 为复杂功能添加集成测试

• 确保在提交之前通过所有测试

• 维护或提高代码覆盖率

有关详细的测试信息，请参阅 测试指南。

提交消息格式

遵循传统的提交格式，类型如下：

• feat: - 新功能

• fix: - 错误修复

• docs: - 文档更改

• test: - 测试添加或修改

• refactor: - 代码重构

• chore: - 维护任务

问题和 Pull Request 标签

该项目使用结构化的标签系统来组织问题和 PR。 主要标签类别包括：

区域标签 (A-)

• A-arch - 架构问题

• A-blocks - 区块处理

• A-clients - 区块链客户端

• A-configs - 配置问题

• A-docs - 文档

• A-tests - 测试

类型标签 (T-)

• T-bug - 错误报告

• T-feature - 新功能

• T-task - 常规任务

• T-documentation - 文档更新

优先级标签 (P-)

• P-high - 关键任务

• P-medium - 重要任务

• P-low - 低优先级

难度标签 (D-)

• D-easy - 初学者友好型

• D-medium - 中级

• D-hard - 复杂问题

代码审查流程

审查要求

• 所有 PR 都需要审查和批准

• 至少需要一位审查者和一位批准者批准

• 在合并之前解决所有审查意见

• 提交在合并时会自动 squash

审查指南

审阅者应关注：

1. 合理性 - 贡献背后的想法是否合理？

2. 架构 - 贡献的架构是否正确？

3. 完善 - 贡献是否完善且准备就绪？

获取审查

如果你的 PR 没有得到关注：

• 在 Telegram 上联系团队

• 确保你的 PR 具有适当的标签

• 保持 PR 的重点突出且大小合理

安全

• 遵循 安全策略

• 通过适当的渠道报告安全漏洞

• 切勿提交敏感信息或凭据

社区准则

行为准则

贡献者必须遵守行为准则，其中：

• 建立尊重协作的标准

• 概述执行程序

• 促进包容性环境

获得帮助

社区支持

• GitHub Discussions: 用于问题和社区互动

• Issues: 用于错误报告和功能请求

• Telegram: 加入我们的社区聊天

• Good First Issues: 查找初学者友好的问题

附加资源

• 完整 CONTRIBUTING.md: 完整的贡献指南

• 用户文档: Monitor 文档

• OpenZeppelin 网站: 主网站

← 测试

• 原文链接： docs.openzeppelin.com/mo...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～