贡献形式

正如我们在《给开发者的信》 中所写的，我们非常欢迎各位开发者为 Taro 社区做出贡献。

贡献之前，请你花一些时间阅读以下内容，保证贡献是符合规范并且能帮助到社区。

“Taro 社区如何运作？我可以怎样参与？”

Taro 接受各种形式的贡献，无论是提交一个重大改动，还是反馈一个问题或参加一次讨论，都能强化 Taro 的网络效应，让 Taro 变得越来越好用。

接下来，我们整理了 Taro 社区日常运营中常遇的各种细分情景。开发者可以从“参与讨论”、“提出问题”开始，一步一步融入社区，和 Taro 互相成就、共同成长。

参与讨论

可以到 Taro 论坛 的对应板块参与讨论。

Taro Github 上不断地产生着 Issues 和 Pull Request，也非常欢迎各位开发者 Review 并参与讨论。

Bug 反馈

请使用 Issue 生成工具 提交 Bug 反馈，并在上尽可能详细地提供一切必要信息，最好能附上一个可复现的 Demo。

一般情况下，信息提供得越完整，响应时间越短。

Feature Request

如果你有一个 Feature Request，请到论坛新建一条帖子进行描述。

Taro 会收集重要的 Feature Requests，在 《来为 Taro 的 Feature Request 投票吧！》 中进行公示，开发者可以根据需要进行投票，需求强烈的特性会被优先支持。

修改文档

文档是开发者与框架沟通的桥梁，但文档一直以来是 Taro 的弱项。一方面我们会不断完善文档，另一方面也希望社区能协助我们把文档做好。

在修改之前请先阅读《贡献指南》，它介绍了 Taro 文档的仓库地址、如何修改等信息。

新想法

无论是 Taro 团队内部还是社区第三方开发者，在为 Taro 提交一个重大特性时，都必须按照 Taro 的 RFC（Request For Comment）机制 进行操作，经过社区讨论完善后再进行代码的提交。

因此如果你对 Taro 的发展有新的想法，如实现一个重要功能、拓展新的使用场景等，需要先撰写对应功能的 RFC 文档，Taro 团队会进行一系列推送，在社区征集意见。

可以访问 taro-rfcs 仓库提交 RFC 或者查看相关的 RFC。

提交代码

“我可以从哪些方向入手？又应该怎么做？”

开发者可以从处理 Issues 入手，这里会列出所有被标记为 good first issue 的 Issues，这是社区专门留给新贡献者的相对简单的入门级 Issues。也可以通过通过 Label 筛选出 Helper Wanted 的 Issues，并且会被分为 Easy、 Medium、 Hard 三种难易程度。

除了帮忙处理 Issues，Taro 还有很多方向需要人力进行建设。

随着对 Taro 内部运行机制的熟悉，开发者可能会产生一些新的想法，例如希望开发一些新的功能等。这时需要先编写 RFC 文档，在社区谈论完善后再开始编码。

在开发之前请先阅读《Taro 的仓库概览》以及《贡献指南》，它们介绍了 Taro 仓库构成、如何开发和提交规范等信息。

如果是首次提交代码，可参考文章：如何参与大型开源项目-Taro 共建。

工具分享

在社区分享你的 “轮子”（例如SDK、组件、插件、UI 库、开源项目等）。

可以提交到 Taro 物料市场、文档《社区优质物料》 、仓库 awesome-taro 里，并提供完善的说明。然后在 Taro 论坛 中添加一条讨论，与开发者进行沟通。

Taro 团队会定期甄选优秀的物料汇集成文，在 Taro 社区和各大有影响力的前端渠道进行推广。

案例分享

分享你的成功案例，可以提交到 taro-user-cases（只需提交小程序码、二维码）。

文章投稿

分享你的经验（教程、文章等），可以给「Taro 社区」公众号投稿。

Credits

感谢以下所有给 Taro 贡献过代码的开发者：