Skip to content

Latest commit

 

History

History
157 lines (114 loc) · 3.33 KB

File metadata and controls

157 lines (114 loc) · 3.33 KB

Contributing to Rust Thinking

感谢你对这个项目感兴趣!我们欢迎各种形式的贡献。

贡献指南

报告 Bug

如果你发现了一个 bug:

  1. 检查它是否已经被报告过
  2. 创建一个 Issue,包含:
    • 问题的清晰描述
    • 复现步骤
    • 预期行为 vs 实际行为
    • Rust 版本 (rustc --version)

建议新功能

有想法改进这个项目?

  1. 先创建一个 Discussion 或 Issue 讨论
  2. 解释为什么这个改进有价值
  3. 等待反馈后再实现

添加新的案例研究

如果你有一个真实的 AI 生成的 bug:

  1. Fork 这个仓库
  2. 创建一个新的分支 case-XX-description
  3. ai-review-cases/case-XX-*/ 下创建结构:
    case-XX-*/
    ├── README.md        (详细分析)
    ├── Cargo.toml
    └── src/main.rs      (问题代码 + 修复方案)
    
  4. 提交 Pull Request

改进文档

文档总能改进!你可以:

  • 修复拼写或语法错误
  • 澄清某个概念
  • 添加更好的例子
  • 翻译成其他语言

改进代码示例

  • 使例子更清晰或更有教育意义
  • 添加更详细的注释
  • 优化代码
  • 添加新的示例

代码风格

Rust 代码

  • 使用 cargo fmt 格式化
  • 遵循 Rust API 指南
  • 添加文档注释和代码注释
  • 写清晰的、有教育意义的代码

示例:

/// 这个函数做什么
///
/// # Examples
/// ```
/// let result = my_function(42);
/// assert_eq!(result, 84);
/// ```
pub fn my_function(x: i32) -> i32 {
    // 清晰的实现
    x * 2
}

Markdown 文档

  • 使用清晰的标题层级
  • 包含代码块时指定语言
  • 保持行长度合理(~80 字符)
  • 在中文文档中,英文单词周围加空格

中文文档规范

  • 使用简体中文
  • 标点符号使用中文全角(,。;等)
  • 代码和英文关键词周围加空格
  • 保持段落简洁易读

Pull Request 流程

  1. Fork 项目
  2. 创建特性分支 (git checkout -b feature/amazing-feature)
  3. 提交改动 (git commit -m '添加 amazing feature')
  4. 推送到分支 (git push origin feature/amazing-feature)
  5. 打开 Pull Request

PR 检查清单

  • 代码通过 cargo check
  • 代码遵循项目风格
  • 添加或更新了相关文档
  • Markdown 没有拼写错误
  • 提供了清晰的描述

提交信息规范

使用有意义的提交信息:

简短的描述 (50字以内)

更详细的说明,如果需要的话。
解释为什么做这个改变,不要只说"修复了什么"。

- 如果有多个改变,可以用列表
- 保持清晰和专业

讨论和问题

  • 用 GitHub Issues 报告 bug
  • 用 GitHub Discussions 进行一般讨论
  • 小问题可以在相关的 Issue 中讨论

行为准则

我们的承诺

我们致力于提供一个开放、欢迎、无骚扰的社区。

我们的标准

不接受的行为包括但不限于:

  • 骚扰、侮辱或贬低性语言
  • 个人攻击
  • 公开或私下的骚扰
  • 发布他人的私人信息
  • 不适当的性或暴力内容

执法

违反行为准则的人可能会被:

  • 暂时禁言
  • 永久封禁
  • 从项目中移除

许可证

通过贡献,你同意你的贡献将在 MIT 许可证下发布。


感谢你的贡献! 🎉

有任何问题,欢迎在 Issues 中讨论。