社区贡献指南¶

**Environment**
- Zephyr version: v3.5.0-123-gabcdef123
- Board: nucleo_f401re
- Toolchain: Zephyr SDK 0.16.3

**Additional context**
The issue doesn't occur with buffer sizes <= 1024 bytes.
DMA configuration in device tree looks correct.

功能建议¶

有好的想法？通过 RFC（Request for Comments）流程提出。

RFC 流程：

1. 在 GitHub Discussions 中讨论：
2. 在 Ideas 分类下创建讨论
3. 描述功能需求和使用场景

4. 收集社区反馈

5. 编写正式 RFC：

6. 如果社区反馈积极，编写详细的 RFC 文档

7. RFC 模板：https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/contribute/rfcs/rfc_template.rst

8. 提交 RFC PR：

9. 将 RFC 文档提交到 doc/contribute/rfcs/ 目录

10. 在 PR 中讨论技术细节

11. TSC 审批：

12. 重大功能需要 TSC 批准
13. 小功能可以直接实现

RFC 示例主题：

• 新的驱动 API 设计
• 内核调度器改进
• 新的子系统支持
• 架构变更

技术工作组¶

加入工作组是深度参与社区的好方式。

工作组列表¶

Architecture Working Group（架构工作组）

• 职责：
• 审查架构变更提案
• 制定架构设计指南

• 解决架构相关的技术债务

• 会议：每两周一次，周三 16:00 UTC

• 如何加入：

• 订阅 arch-wg@lists.zephyrproject.org
• 参加会议
• 参与 RFC 讨论

Security Working Group（安全工作组）

• 职责：
• 处理安全漏洞报告
• 审查安全相关代码

• 制定安全编码规范

• 会议：每月一次

• 如何加入：

• 订阅 security-wg@lists.zephyrproject.org
• 需要签署保密协议（处理未公开漏洞）

Testing Working Group（测试工作组）

• 职责：
• 维护 Twister 测试框架
• 改进 CI/CD 流程

• 提高测试覆盖率

• 会议：每两周一次

• 如何加入：

• 订阅 testing-wg@lists.zephyrproject.org
• 贡献测试用例
• 改进测试工具

Documentation Working Group（文档工作组）

• 职责：
• 维护官方文档
• 审查文档 PR

• 组织文档翻译

• 会议：每月一次

• 如何加入：

• 订阅 docs-wg@lists.zephyrproject.org
• 贡献文档改进
• 参与翻译工作

贡献机会¶

每个工作组都有适合不同技能水平的贡献机会：

初级贡献：

• 修复文档错误
• 改进示例代码
• 添加测试用例
• 翻译文档

中级贡献：

• 实现新功能
• 优化性能
• 修复复杂 Bug
• 编写技术文档

高级贡献：

• 架构设计
• 安全审计
• 性能分析
• 指导新贡献者

成为 Maintainer 的路径¶

Maintainer 是 Zephyr 社区的核心力量，负责特定子系统的维护。

Maintainer 职责¶

代码维护：

• 审查和合并 Pull Request
• 修复 Bug 和实现新特性
• 维护代码质量和一致性
• 管理子系统的技术债务

社区支持：

• 回答用户问题
• 指导新贡献者
• 参与技术讨论
• 代表子系统参加工作组会议

规划和决策：

• 制定子系统发展路线图
• 审查架构变更提案
• 参与版本发布规划
• 协调跨子系统的工作

Maintainer 权限¶

• 合并 PR 到主仓库
• 管理子系统的 Issue 和 PR
• 参与 TSC 投票（部分 Maintainer）
• 访问 CI/CD 基础设施

成为 Maintainer 的步骤¶

1. 持续贡献（6-12 个月）

• 定期提交高质量的 PR
• 参与代码审查
• 帮助其他贡献者
• 展示对子系统的深入理解

典型贡献路径：

graph LR
    A[首次贡献] --> B[定期贡献]
    B --> C[代码审查]
    C --> D[指导新人]
    D --> E[子系统专家]
    E --> F[Maintainer 提名]
    F --> G[TSC 批准]
    G --> H[成为 Maintainer]

    style A fill:#e1f5ff
    style B fill:#b3e5fc
    style C fill:#81d4fa
    style D fill:#4fc3f7
    style E fill:#29b6f6
    style F fill:#03a9f4
    style G fill:#039be5
    style H fill:#0288d1

2. 建立信任

• 代码质量始终如一
• 及时响应审查意见
• 遵守社区规范
• 展示技术领导力

3. 获得提名

• 现有 Maintainer 提名
• 或自我提名（需要展示贡献记录）
• 提名邮件发送到 devel 邮件列表

提名邮件示例：

Subject: Maintainer nomination: Zhang San for drivers/serial

Hi all,

I would like to nominate Zhang San as a maintainer for the serial 
drivers subsystem.

Zhang San has been an active contributor for the past 12 months:
- 25+ merged PRs, including major features and bug fixes
- Consistently high-quality code reviews
- Active in helping users on Discord and mailing list
- Deep understanding of UART hardware and driver architecture

Recent contributions:
- Implemented DMA support for STM32 UART (#12345)
- Fixed critical bug in nRF UART driver (#12346)
- Improved UART API documentation (#12347)

I believe Zhang San would be an excellent addition to the maintainer team.

Best regards,
Current Maintainer

4. TSC 审批

• TSC 审查提名
• 社区讨论（通常 1-2 周）
• TSC 投票决定
• 批准后更新 MAINTAINERS.yml

Maintainer 最佳实践¶

代码审查：

• 及时审查 PR（目标：48 小时内首次响应）
• 提供建设性的反馈
• 解释"为什么"而不仅仅是"做什么"
• 鼓励新贡献者

沟通：

• 保持透明和开放
• 及时回复邮件和 Issue
• 主动分享技术决策的理由
• 尊重不同意见

技术领导：

• 制定清晰的技术方向
• 平衡短期需求和长期架构
• 推动技术债务的解决
• 培养新的贡献者

时间管理：

• Maintainer 工作通常是志愿的
• 合理分配时间
• 必要时寻求帮助
• 避免过度承诺

实际贡献案例¶

让我们看几个真实的贡献案例，学习成功的经验。

案例 1：修复一个 Bug¶

背景：

• 贡献者：李明（化名），嵌入式工程师，Zephyr 使用 6 个月
• 问题：nRF52840 的 GPIO 中断在高频触发时丢失事件
• 影响：影响按键检测和外部传感器数据采集

贡献过程：

1. 问题发现和复现

// 测试代码：快速触发 GPIO 中断
void button_test(void)
{
    int count = 0;

    // 配置 GPIO 中断
    gpio_pin_interrupt_configure(gpio_dev, BUTTON_PIN, 
                                  GPIO_INT_EDGE_BOTH);

    // 快速按压按钮 100 次
    // 预期：count = 200（按下 + 释放）
    // 实际：count = 150-180（丢失事件）
}

2. 问题分析

• 使用逻辑分析仪捕获 GPIO 信号
• 发现硬件确实产生了所有中断
• 问题在于驱动的中断处理逻辑

3. 定位根因

// drivers/gpio/gpio_nrfx.c
// 问题代码：
static void gpio_nrfx_isr(const struct device *dev)
{
    // 读取中断状态
    uint32_t status = nrf_gpio_latch_get();

    // 清除中断标志
    nrf_gpio_latch_clear();  // ❌ 太早清除，可能丢失新中断

    // 处理中断
    for (int i = 0; i < 32; i++) {
        if (status & BIT(i)) {
            // 调用回调
            fire_callback(dev, i);
        }
    }
}

4. 修复方案

// 修复后的代码：
static void gpio_nrfx_isr(const struct device *dev)
{
    // 读取中断状态
    uint32_t status = nrf_gpio_latch_get();

    // 处理中断
    for (int i = 0; i < 32; i++) {
        if (status & BIT(i)) {
            // 调用回调
            fire_callback(dev, i);
        }
    }

    // 处理完成后再清除中断标志
    nrf_gpio_latch_clear();  // ✅ 确保不丢失新中断
}

5. 添加测试

// tests/drivers/gpio/gpio_api/src/test_gpio_interrupt.c
ZTEST(gpio_api, test_gpio_high_frequency_interrupt)
{
    int count = 0;

    // 配置中断
    gpio_pin_interrupt_configure(gpio_dev, TEST_PIN, 
                                  GPIO_INT_EDGE_BOTH);

    // 模拟高频中断（使用定时器触发）
    for (int i = 0; i < 100; i++) {
        gpio_emul_trigger(gpio_dev, TEST_PIN);
        k_busy_wait(100);  // 100us 间隔
    }

    // 验证所有中断都被处理
    zassert_equal(count, 100, "Missed interrupts: %d", 100 - count);
}

6. 提交 PR

• Commit 消息遵循规范
• PR 描述清晰，包含问题分析和测试结果
• 响应审查意见，添加更多测试用例
• 2 周后合并

成果：

• 修复了影响多个项目的关键 Bug
• 获得社区认可
• 建立了在 GPIO 子系统的专业声誉

案例 2：添加新的驱动¶

背景：

• 贡献者：王芳（化名），硬件工程师，Zephyr 使用 1 年
• 目标：为 AHT20 温湿度传感器添加驱动支持
• 动机：项目需要，官方尚未支持

贡献过程：

1. 研究现有驱动

# 查看类似的传感器驱动
ls drivers/sensor/
# 参考 SHT3x 驱动（类似的 I2C 温湿度传感器）

2. 实现驱动

// drivers/sensor/aht20/aht20.c
#define DT_DRV_COMPAT aosong_aht20

struct aht20_data {
    uint16_t temperature;
    uint16_t humidity;
};

struct aht20_config {
    struct i2c_dt_spec i2c;
};

static int aht20_sample_fetch(const struct device *dev,
                               enum sensor_channel chan)
{
    const struct aht20_config *cfg = dev->config;
    struct aht20_data *data = dev->data;
    uint8_t cmd[] = {0xAC, 0x33, 0x00};  // 触发测量命令
    uint8_t buf[7];
    int ret;

    // 发送测量命令
    ret = i2c_write_dt(&cfg->i2c, cmd, sizeof(cmd));
    if (ret < 0) {
        return ret;
    }

    // 等待测量完成（80ms）
    k_sleep(K_MSEC(80));

    // 读取数据
    ret = i2c_read_dt(&cfg->i2c, buf, sizeof(buf));
    if (ret < 0) {
        return ret;
    }

    // 解析数据
    uint32_t raw_humidity = ((uint32_t)buf[1] << 12) | 
                            ((uint32_t)buf[2] << 4) | 
                            (buf[3] >> 4);
    uint32_t raw_temp = (((uint32_t)buf[3] & 0x0F) << 16) | 
                        ((uint32_t)buf[4] << 8) | 
                        buf[5];

    // 转换为标准单位
    data->humidity = (raw_humidity * 100) / 1048576;
    data->temperature = ((raw_temp * 200) / 1048576) - 50;

    return 0;
}

static int aht20_channel_get(const struct device *dev,
                              enum sensor_channel chan,
                              struct sensor_value *val)
{
    struct aht20_data *data = dev->data;

    switch (chan) {
    case SENSOR_CHAN_AMBIENT_TEMP:
        val->val1 = data->temperature / 100;
        val->val2 = (data->temperature % 100) * 10000;
        break;
    case SENSOR_CHAN_HUMIDITY:
        val->val1 = data->humidity / 100;
        val->val2 = (data->humidity % 100) * 10000;
        break;
    default:
        return -ENOTSUP;
    }

    return 0;
}

static const struct sensor_driver_api aht20_api = {
    .sample_fetch = aht20_sample_fetch,
    .channel_get = aht20_channel_get,
};

static int aht20_init(const struct device *dev)
{
    const struct aht20_config *cfg = dev->config;

    if (!device_is_ready(cfg->i2c.bus)) {
        return -ENODEV;
    }

    // 软复位
    uint8_t reset_cmd = 0xBA;
    i2c_write_dt(&cfg->i2c, &reset_cmd, 1);
    k_sleep(K_MSEC(20));

    return 0;
}

#define AHT20_DEFINE(inst)                                          \
    static struct aht20_data aht20_data_##inst;                     \
    static const struct aht20_config aht20_config_##inst = {        \
        .i2c = I2C_DT_SPEC_INST_GET(inst),                          \
    };                                                              \
    DEVICE_DT_INST_DEFINE(inst, aht20_init, NULL,                   \
                          &aht20_data_##inst, &aht20_config_##inst, \
                          POST_KERNEL, CONFIG_SENSOR_INIT_PRIORITY, \
                          &aht20_api);

DT_INST_FOREACH_STATUS_OKAY(AHT20_DEFINE)

3. 添加设备树绑定

# dts/bindings/sensor/aosong,aht20.yaml
description: AHT20 temperature and humidity sensor

compatible: "aosong,aht20"

include: [sensor-device.yaml, i2c-device.yaml]

properties:
  # 继承 I2C 设备属性

4. 添加 Kconfig

# drivers/sensor/aht20/Kconfig
config AHT20
    bool "AHT20 temperature and humidity sensor"
    default y
    depends on DT_HAS_AOSONG_AHT20_ENABLED
    depends on I2C
    help
      Enable driver for AHT20 temperature and humidity sensor.

5. 编写测试

// tests/drivers/sensor/aht20/src/main.c
ZTEST(aht20, test_aht20_read)
{
    const struct device *dev = DEVICE_DT_GET_ONE(aosong_aht20);
    struct sensor_value temp, humidity;

    zassert_true(device_is_ready(dev), "Device not ready");

    // 读取传感器数据
    int ret = sensor_sample_fetch(dev);
    zassert_equal(ret, 0, "Failed to fetch sample");

    ret = sensor_channel_get(dev, SENSOR_CHAN_AMBIENT_TEMP, &temp);
    zassert_equal(ret, 0, "Failed to get temperature");

    ret = sensor_channel_get(dev, SENSOR_CHAN_HUMIDITY, &humidity);
    zassert_equal(ret, 0, "Failed to get humidity");

    // 验证数据范围合理
    zassert_true(temp.val1 >= -40 && temp.val1 <= 85, 
                 "Temperature out of range");
    zassert_true(humidity.val1 >= 0 && humidity.val1 <= 100, 
                 "Humidity out of range");
}

6. 编写文档

.. _aht20:

AHT20: Temperature and Humidity Sensor
#######################################

Overview
********

The AHT20 is a temperature and humidity sensor with I2C interface.

Supported Features
******************

* Temperature measurement (-40°C to +85°C)
* Humidity measurement (0% to 100% RH)
* I2C interface (address 0x38)

Configuration
*************

Device Tree
===========

.. code-block:: devicetree

   &i2c0 {
       aht20@38 {
           compatible = "aosong,aht20";
           reg = <0x38>;
       };
   };

API Usage
*********

.. code-block:: c

   const struct device *dev = DEVICE_DT_GET_ONE(aosong_aht20);
   struct sensor_value temp, humidity;

   sensor_sample_fetch(dev);
   sensor_channel_get(dev, SENSOR_CHAN_AMBIENT_TEMP, &temp);
   sensor_channel_get(dev, SENSOR_CHAN_HUMIDITY, &humidity);

   printk("Temperature: %d.%d C\n", temp.val1, temp.val2 / 10000);
   printk("Humidity: %d.%d %%\n", humidity.val1, humidity.val2 / 10000);

7. 提交 PR

• 包含驱动代码、绑定、测试、文档
• PR 描述包含硬件规格和测试结果
• 提供示例应用
• 响应审查，改进代码质量

成果：

• 成功合并，成为官方支持的传感器
• 帮助其他开发者快速集成 AHT20
• 在传感器子系统建立专业声誉
• 后续成为传感器子系统的活跃贡献者

案例 3：改进文档¶

背景：

• 贡献者：陈华（化名），技术写作爱好者，Zephyr 新手
• 问题：官方文档的入门指南对新手不够友好
• 目标：改进文档，降低学习门槛

贡献过程：

1. 识别问题

• 自己学习 Zephyr 时遇到困难
• 在社区看到很多新手提类似的问题
• 官方文档缺少详细的故障排除指南

2. 提出改进建议

在 GitHub Discussions 发起讨论：

Title: Improve Getting Started Guide for Beginners

Hi all,

As a Zephyr beginner, I found the getting started guide could be improved:

1. Missing troubleshooting section for common installation issues
2. No explanation of what each command does
3. Lack of "what to do next" guidance after hello_world

I'd like to contribute improvements. Would this be welcome?

Specific improvements I'm thinking of:
- Add troubleshooting section with common errors
- Add explanations for each command
- Add "next steps" section with learning path

Feedback welcome!

3. 获得社区支持

• Documentation WG 表示欢迎
• 其他用户分享了他们遇到的问题
• Maintainer 提供了改进建议

4. 编写改进内容

.. _getting_started_troubleshooting:

Troubleshooting
***************

This section covers common issues encountered during installation.

Python Version Issues
=====================

**Symptom:**

.. code-block:: console

   ERROR: Python 3.8 or newer is required

**Solution:**

Zephyr requires Python 3.8 or newer. Check your Python version:

.. code-block:: console

   python3 --version

If your version is older, install a newer Python:

**Ubuntu/Debian:**

.. code-block:: console

   sudo apt install python3.10

**macOS:**

.. code-block:: console

   brew install python@3.10

**Windows:**

Download from https://www.python.org/downloads/

west update Fails
=================

**Symptom:**

.. code-block:: console

   ERROR: Failed to clone repository

**Possible Causes:**

1. **Network issues:** Check your internet connection
2. **Firewall/Proxy:** Configure git proxy if behind corporate firewall
3. **Disk space:** Ensure you have at least 5GB free space

**Solutions:**

For proxy issues:

.. code-block:: console

   git config --global http.proxy http://proxy.example.com:8080

For slow connections, use shallow clone:

.. code-block:: console

   west update --narrow

Compilation Errors
==================

**Symptom:**

.. code-block:: console

   ERROR: Toolchain not found

**Solution:**

Ensure Zephyr SDK is installed and environment is set up:

.. code-block:: console

   # Check SDK installation
   ls $ZEPHYR_SDK_INSTALL_DIR

   # Re-run environment setup
   source zephyr/zephyr-env.sh

Next Steps
**********

After successfully running hello_world, here's your learning path:

1. **Explore Basic Samples**

   Try the blinky sample to learn GPIO control:

   .. code-block:: console

      west build -b your_board samples/basic/blinky
      west flash

2. **Learn Project Structure**

   Understand how Zephyr projects are organized:
   - CMakeLists.txt: Build configuration
   - prj.conf: Kconfig options
   - src/: Source code

3. **Read Core Documentation**

   - :ref:`kernel`: Understand threads, scheduling
   - :ref:`device_model`: Learn device drivers
   - :ref:`devicetree`: Configure hardware

4. **Join the Community**

   - Subscribe to mailing list
   - Join Discord chat
   - Ask questions on GitHub Discussions

5. 添加图表

Learning Path
=============

.. mermaid::

   graph LR
       A[Install Zephyr] --> B[Hello World]
       B --> C[Basic Samples]
       C --> D[Learn Concepts]
       D --> E[Build Projects]
       E --> F[Contribute Back]

       style A fill:#e1f5ff
       style B fill:#b3e5fc
       style C fill:#81d4fa
       style D fill:#4fc3f7
       style E fill:#29b6f6
       style F fill:#03a9f4

6. 提交 PR

• PR 标题：doc: getting_started: Add troubleshooting and next steps
• 详细说明改进内容和动机
• 请求 Documentation WG 审查

7. 响应审查

Reviewer: "Great improvements! Can you also add a section about board selection?"
Response: "Good idea! Added a 'Choosing Your Board' section with comparison table."

Reviewer: "Some commands are outdated for Windows."
Response: "Fixed. Tested all commands on Windows 11."

成果：

• 文档改进被合并
• 帮助数百名新用户更顺利地入门
• 建立了在文档领域的贡献记录
• 后续继续改进其他文档章节
• 6 个月后被邀请加入 Documentation WG

案例 4：参与 RFC 讨论¶

背景：

• 贡献者：刘强（化名），系统架构师，Zephyr 使用 2 年
• 场景：社区提出新的电源管理 API 设计
• 目标：基于实际项目经验提供反馈

贡献过程：

1. 阅读 RFC

RFC 提案：重新设计设备电源管理 API

RFC: Device Power Management API Redesign
==========================================

Problem Statement
-----------------

Current device PM API has several limitations:
1. No support for partial power states
2. Difficult to coordinate multiple devices
3. Lack of power budget management

Proposed Solution
-----------------

New API design:

.. code-block:: c

   // New power state enum
   enum pm_device_state {
       PM_DEVICE_STATE_ACTIVE,
       PM_DEVICE_STATE_IDLE,
       PM_DEVICE_STATE_STANDBY,
       PM_DEVICE_STATE_SUSPEND,
       PM_DEVICE_STATE_OFF,
   };

   // New API
   int pm_device_state_set(const struct device *dev,
                           enum pm_device_state state);
   int pm_device_state_get(const struct device *dev,
                           enum pm_device_state *state);

2. 基于实际经验提供反馈

在 RFC PR 中评论：

Thanks for this RFC! I've been working on a battery-powered IoT device 
and have some feedback based on real-world usage:

## Positive Aspects

1. The new state enum is much clearer than the old API
2. Separating IDLE and STANDBY states is very useful

## Concerns

### 1. Missing Transition Time Information

In our project, we need to know how long it takes to transition between 
states to make optimal power decisions. For example:

- ACTIVE → STANDBY: 10ms
- STANDBY → ACTIVE: 50ms

If we're only idle for 30ms, it's not worth going to STANDBY.

**Suggestion:** Add transition time query API:

```c
int pm_device_transition_time_get(const struct device *dev,
                                   enum pm_device_state from,
                                   enum pm_device_state to,
                                   uint32_t *time_us);

2. Power Consumption Information¶

We also need to know the power consumption of each state to calculate battery life. Current API doesn't provide this.

Suggestion: Add power consumption query:

int pm_device_power_get(const struct device *dev,
                        enum pm_device_state state,
                        uint32_t *power_uw);  // microwatts

3. Dependency Management¶

In our system, some devices depend on others (e.g., sensor depends on I2C bus). The API should handle dependencies automatically.

Suggestion: Add dependency declaration in device tree:

sensor@48 {
    compatible = "vendor,sensor";
    pm-dependencies = <&i2c0>;
};

Real-World Example¶

Here's how we currently handle power management (pseudocode):

// Calculate if it's worth entering low power mode
uint32_t idle_time = predict_idle_time();
uint32_t transition_time = get_transition_time(ACTIVE, STANDBY);
uint32_t active_power = get_power_consumption(ACTIVE);
uint32_t standby_power = get_power_consumption(STANDBY);

// Only enter standby if we save energy
if (idle_time > transition_time * 2) {
    uint32_t energy_saved = (active_power - standby_power) * idle_time;
    uint32_t energy_cost = active_power * transition_time * 2;

    if (energy_saved > energy_cost) {
        pm_device_state_set(dev, PM_DEVICE_STATE_STANDBY);
    }
}

This logic should be built into the PM subsystem, not reimplemented by every application.

Conclusion¶

The RFC is a good start, but needs additional APIs for: 1. Transition time queries 2. Power consumption queries
3. Automatic dependency management

I'm happy to help implement these features if the community agrees.

**3. 参与讨论**

其他开发者回应：

Developer B: "Transition time is critical. We should definitely add this."

RFC Author: "Thanks for the detailed feedback! I'll update the RFC to include transition time and power consumption APIs."

Maintainer: "Dependency management is complex. Let's discuss this in the next Architecture WG meeting."

**4. 协助改进 RFC**

- 参加 Architecture WG 会议讨论细节
- 提供设备树绑定的具体设计
- 编写示例代码展示 API 使用

**5. 实现部分功能**

RFC 批准后，主动实现部分功能：

```c
// 实现过渡时间查询 API
int pm_device_transition_time_get(const struct device *dev,
                                   enum pm_device_state from,
                                   enum pm_device_state to,
                                   uint32_t *time_us)
{
    const struct pm_device_data *pm_data = dev->pm;

    if (!pm_data || !pm_data->transition_times) {
        return -ENOTSUP;
    }

    *time_us = pm_data->transition_times[from][to];
    return 0;
}

成果：

• RFC 采纳了大部分建议
• 新 API 更加实用和完善
• 建立了在电源管理领域的专业声誉
• 后续成为电源管理子系统的活跃贡献者
• 1 年后成为电源管理子系统的 Co-Maintainer

实操任务¶

通过实际行动开始你的社区贡献之旅。

任务 1：在 GitHub 上提交一个 Issue¶

目标：学习如何正确报告问题

步骤：

1. 寻找问题：
2. 在使用 Zephyr 过程中遇到的 Bug
3. 文档中的错误或不清楚的地方

4. 缺失的功能或改进建议

5. 搜索已有 Issue：

   在 GitHub 搜索框输入关键词
   检查是否已有人报告相同问题
   

6. 创建 Issue：

7. 访问 https://github.com/zephyrproject-rtos/zephyr/issues/new/choose
8. 选择合适的 Issue 模板（Bug Report / Feature Request）

9. 填写所有必需字段

10. 提供完整信息：

11. Zephyr 版本（commit hash）
12. 硬件平台
13. 完整的错误信息
14. 最小可复现步骤

15. 配置文件

16. 跟进 Issue：

17. 及时回复维护者的问题
18. 提供额外的信息
19. 测试建议的解决方案

评估标准：

• ✅ Issue 描述清晰完整
• ✅ 提供了足够的复现信息
• ✅ 及时响应维护者的询问
• ✅ Issue 得到确认或解决

任务 2：修复一个 Good First Issue 并提交 PR¶

目标：完成第一个代码贡献

步骤：

1. 寻找 Good First Issue：
2. 访问 https://github.com/zephyrproject-rtos/zephyr/labels/good%20first%20issue
3. 选择一个你感兴趣且能力范围内的 Issue

4. 在 Issue 中评论表示你想处理这个问题

5. 设置开发环境：

   # Fork 仓库
   # Clone 到本地
   git clone https://github.com/YOUR_USERNAME/zephyr.git
   cd zephyr
   git remote add upstream https://github.com/zephyrproject-rtos/zephyr.git
   
   # 创建分支
   git checkout -b fix-issue-12345 upstream/main
   

6. 修复问题：

7. 理解问题的根本原因
8. 编写修复代码
9. 添加或更新测试

10. 运行 checkpatch 检查代码风格

11. 提交代码：

    git add .
    git commit -s -m "area: Fix issue description
    
    Detailed explanation of the fix.
    
    Fixes #12345"
    
    git push origin fix-issue-12345
    

12. 创建 Pull Request：

13. 在 GitHub 上创建 PR
14. 填写 PR 模板

15. 等待 CI 检查通过

16. 响应审查：

17. 及时回复审查意见
18. 修改代码并更新 PR
19. 保持耐心和礼貌

评估标准：

• ✅ 代码符合 Zephyr 编码规范
• ✅ 包含适当的测试
• ✅ Commit 消息符合规范
• ✅ 及时响应审查意见
• ✅ PR 最终被合并

任务 3：参与一次社区讨论或会议¶

目标：融入社区，建立联系

选项 A：参与邮件列表讨论

1. 订阅 devel@lists.zephyrproject.org
2. 阅读最近的讨论主题
3. 选择一个你有见解的话题
4. 撰写有价值的回复
5. 参与后续讨论

选项 B：参加工作组会议

1. 选择一个感兴趣的工作组
2. 订阅工作组邮件列表
3. 查看会议时间和议程
4. 参加在线会议（通常使用 Zoom）
5. 在会议中提问或分享观点

选项 C：在 Discord 上帮助他人

1. 加入 Zephyr Discord 服务器
2. 在 #help 频道浏览问题
3. 选择你能回答的问题
4. 提供详细和有帮助的回答
5. 持续参与社区互动

评估标准：

• ✅ 积极参与讨论
• ✅ 提供有价值的见解
• ✅ 尊重他人观点
• ✅ 建立社区联系

学习总结¶

完成本章学习后，你应该掌握：

社区理解：

• ✅ 了解 Zephyr 社区的组织结构和运作方式
• ✅ 认识各个工作组的职责和参与方式
• ✅ 理解开源协作的价值和意义

贡献技能：

• ✅ 掌握 GitHub Fork + PR 工作流程
• ✅ 遵守代码规范和 Commit 消息规范
• ✅ 能够编写高质量的 Bug 报告和功能建议
• ✅ 理解 Code Review 流程和最佳实践

社区参与：

• ✅ 知道如何使用邮件列表、Discord、GitHub Discussions
• ✅ 能够参与技术讨论和 RFC 评审
• ✅ 了解如何加入工作组和参加会议

职业发展：

• ✅ 理解从贡献者到 Maintainer 的成长路径
• ✅ 建立开源贡献的个人品牌
• ✅ 通过社区贡献提升技术影响力

进阶资源¶

官方资源：

• Zephyr 贡献指南
• 代码规范
• Commit 消息规范
• MAINTAINERS.yml

社区链接：

• GitHub 仓库
• 邮件列表
• Discord 服务器
• 开发者峰会

学习资源：

• How To Ask Questions The Smart Way
• GitHub Flow
• Conventional Commits
• Code Review Best Practices

中文社区：

• 微信公众号：Zephyr RTOS 中文社区
• 知乎专栏：Zephyr RTOS 实战
• B站：搜索"Zephyr RTOS"
• GitHub：zephyr-chinese-community

下一步¶

完成社区贡献学习后，建议：

1. 持续贡献：
2. 每月至少提交 1 个 PR
3. 参与代码审查

4. 帮助新贡献者

5. 深入专业领域：

6. 选择一个子系统深入研究
7. 成为该领域的专家

8. 争取成为 Maintainer

9. 技术布道：

10. 撰写技术博客
11. 制作视频教程
12. 在技术会议上演讲

13. 参考下一章：技术布道

14. 建立影响力：

15. 在社区中建立声誉
16. 参与技术决策
17. 指导新人成长
18. 推动技术创新

恭喜你完成第四阶段的社区贡献学习！

你已经掌握了参与开源社区的核心技能，现在是时候将知识转化为行动，成为 Zephyr 社区的活跃贡献者。记住，最好的学习方式就是实践和分享。开始你的贡献之旅吧！