Import the best practice from https://github.com/LinuxSuRen/surenpi/wiki

Author: LinuxSuRen

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2021 Rick
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -0,0 +1,59 @@
+## Get started
+仔细阅读项目自述文件（README），遵循贡献指南（CONTRIBUTION）中给出的流程。
+
+面对一个新的项目，尤其是在相对不熟悉的领域，有如下的方法可以帮助你提供前期的贡献：
+* 文档贡献，这是非常有效的一种了解项目的方式，通常我们可以在阅读文档的过程中，修复一些错别字、标点符号、语法错误、无效链接等等
+* good-first-issues，对于希望收到更多贡献的项目而言，会在一些容易上手的 issues 上添加该标签
+
+## Issues
+常见误区：
+* 只有标题，没有内容
+* 只有结果、现象，没有提供上下文
+  * 问题出现的可能性千千万，没有人能猜到你的环境、操作步骤
+* 只有截图，不提供错误、异常、上下文的关键文字
+  * 没有文字的话，不便于其他人进行检索
+
+最佳实践：
+* 现有的 issues 中没有提到过该问题时再提交新的
+* 标题要简洁、规范
+* 做好分类，可以通过标签或者标题前缀来分类
+  * 常见的标题分类法：Question: xxx, Proposal: xxx, Bug: xxx
+
+## Pull Request
+常见误区：
+* 使用单一分支（例如：master）提交变更
+* 单个 PR 中包含多个不同的优化、缺陷修复
+* 单个 PR 不断新增内容
+* 合并自己提交的 PR
+* 通过及时聊天工具催促特定的人 review 你的 PR
+
+最佳实践：
+* 首次提交 PR 前，浏览已经成功合并过的 PR 评论列表以及格式等
+* 如果要修复的问题已经有对应的 issue，请确保没有人提交对应的 PR，然后，请留言说明你的修复计划
+* 如果估计你提交的变更比较多，请首先创建 issue，并依据具体情况（难易程度、争议性等）描述你的想法
+* 一个 PR 只能包含一类修改
+* 每次提交都须要新增一个分支进行
+* 避免同一个主题的 PR 反复关闭、新建
+  * 避免在同一个 PR 中频繁地提交，这对于 reviewers 来说将会是极大的困扰
+  * 如果你的 PR 还没有准备好接受 review，请在标题上添加前缀 `WIP: `，直到你自测充分
+  * 在根据 reviewers 提出的建议进行修改时，避免使用强制推送 `--force`，这对于 reviewers 来说将无法轻松地看到你最新的修改部分
+  * 尽可能保持你的 commit 记录比较优雅，万一多次 review 后的记录比较多的话，项目 owners 会在合并时决定是否会 squash 你的提交记录
+* 尽可能多地给出当前 PR 的详情，包括但不限于：相关 issues、解决的问题、任何方便 review 的上下文
+  * 涉及到 UI 的改动，给出修改前后的效果截图
+  * 视情况给出你的自测过程
+  * 对于可能引起争议的部分，给出你的解释
+* 如果你的 PR 超过一周没有得到 review，可以尝试 cc 相关的 team
+  * 如果没有相关的 team 可以 cc 的话，可以找最近合并过类似 PR 的人，并说明是由于找不到其他的方式，以及表示抱歉打扰
+
+## 社区运营
+
+### SIG 会议
+
+* 每次会议都要有会议开始和结束的表述，例如：现在开始我们今天的例会；结束时可以说：“非常感谢各位参加今天的社区例会”等等的
+
+#### 表述方式
+* 避免使用类似于“我们昨天讨论过xxx”的表述，社区成员无法了解到你们讨论的内容
+
+## 其他
+还有一些其他的比较推荐的习惯、方法：
+* 习惯查看邮件

mentor-plan.md

@@ -0,0 +1,48 @@
+# 如何让开源社区持续保持活跃
+
+# 开源导师计划
+
+开源导师计划，为了给有兴趣深入参与开源，并希望得到一定指导的人一次共同学习的机会。
+
+需要注意的是，导师制并不是要培训、讲解如何参与开源，更不是教你学习任何具体的技术。这个计划大致的形式是：导师给出一系列任务，参与者来完成任务。以下是细节：
+
+## 周期
+一年
+
+## 参与者人数
+不超过两人
+
+## 进度同步
+两周一次
+
+## 任务
+参与者需要和导师共同制定要完成的任务，并明确完成的标准。导师应该根据学员的具体情况给出相应的指导意见。
+
+### 选择一上游社区并跟进
+形式包括但不限于：
+* 每月至少参与一次社区例会
+* 了解社区运营方式
+* 至少参与一次社区的活动
+* 提交一次代码 PR，已经其他 PR 若干
+
+### 跟进本社区的一名外部贡献者
+形式包括但不限于：
+* 积极跟进对方提的 issue 或者 PR
+* 了解对方在参与奔社区过程中遇到的困境，并设法解决
+* 进行2～3次的访谈，并形成文字记录
+
+## 成果展示
+一个季度一次
+
+* 技术博文
+* 社区动态介绍，包括：技术、社区活动
+* 视频教程
+* 所跟进的外部贡献者的成果，收到的反馈
+
+### 通用技能
+* 英语（听说读写）
+* 演讲
+
+## 同步、交流
+* 例会，两周一次
+* 成果展示，每月一次