Skip to content

Latest commit

 

History

History
208 lines (169 loc) · 10.5 KB

CONTRIBUTING-CH.md

File metadata and controls

208 lines (169 loc) · 10.5 KB
Raw

Contributing

非常感谢贡献 Davinci！在参与贡献之前，请仔细阅读以下指引。

贡献范畴

Bug 反馈与修复

我们建议无论是 Bug 反馈还是修复，都先创建一个 Issue 来仔细描述 Bug 的状况，以助于社区可以通过 Issue 记录来找到和回顾问题以及代码。Bug 反馈 Issue 通常需要包含完整描述 Bug 的信息以及可复现的场景，这样社区才能快速定位导致 Bug 的原因并修复它。包含 #bug 标签的打开的 Issue 都是需要被修复的。

功能交流、实现、重构

在交流过程中，详细描述新功能（或重构）的细节、机制和使用场景，能够促使它更好更快地被实现。如果计划实现一个重大的功能（或重构），请务必通过 Issue 或其他方式与核心开发团队进行沟通，这样大家能以最效率的方式来推进它。包含 #feature 标签的打开的 Issue 都是需要被实现的新功能，包含 #enhancement 标签的打开的 Issue 都是需要改进重构的功能。

Issue 答疑

帮助回答 Issue 中的使用问题是为 Davinci 社区做贡献的一个非常有价值的方式；社区中总会有新用户不断进来，在帮助新用户的同时，也可以展现你的专业知识。

文档改进

Davinci 用户手册文档在 docs/ 目录下，我们使用了 jekyll 作为 Davinci 的文档服务，可以编辑目录里的 Markdown 文件来对文档做改进。

国际化

非常抱歉，Davinci 目前仅支持中文语言；但项目前端依赖包含 react-intl，代码结构上也支持国际化，欢迎对其他语言进行贡献。

贡献流程

分支结构

Davinci 源码可能会产生一些临时分支，但真正有明确意义的只有以下三个分支：

  • master: 最近一次稳定 release 的源码，偶尔会多几次 hotfix 提交；
  • dev-0.3: 主要开发分支；
  • dev-0.2: 0.2 版本源码，目前 0.2 版本已经停止更新，如有 0.2 版本使用者或是需要进行二次开发的用户可以参考此分支。

开发指引

Davinci 前后端代码共用同一个代码库，但在开发上是分离的。在着手开发之前，请先将 Davinci 项目 fork 一份到自己的 Github Repositories 中， 开发时请基于自己 Github Repositories 中的 Davinci 代码库进行开发。

我们建议克隆 dev-0.3 分支来开发，这样在向 Davinci 主项目提交 PR 时合并冲突的可能性会小很多

git clone https://github.com/yourname/davinci.git --branch dev-0.3

前端

前端代码在 webapp/ 目录中

目录结构
├── app              # 主应用源码
  ├── assets           # 资源文件
  ├── components       # 通用组件
  ├── containers       # 路由容器组件
  ├── utils            # 通用实用方法
  └── app.tsx          # 主应用入口
├── internals        # 开发工程文件
├── libs             # 改动后的项目依赖
├── server           # 开发服务器
├── share            # 分享页源码
└── package.json
开发
npm install
npm start
Lint
npm run lint
Test
npm run test
打包
npm run build

后端

用户配置在项目根目录 /config/ 下，项目启动脚本和升级补丁脚本在项目根目录 /bin/ 下， 后端代码及核心配置在 server/ 目录下, 日志在项目根目录 /log/ 下。注意：此处所指项目根目录都指环境变量 DAVINCI3_HOME 所配置的目录，在使用 IDE 开发过程中也需要配置环境变量，如 Idea 关于环境变量加载的优先级：Run/Debug Configurations 中配置的 Environment variables —> IDE缓存的系统环境变量。

目录结构

脚本

├── bin                   # 脚本目录
  ├── migration             # 较大版本变动迁移脚本目录
  ├── patch                 # 数据库补丁
  	 ├── 001_beta5.sql        # 已发布补丁（命名规则：“序列_版本”）
  	 └── beta.sql             # 当期未发布补丁（固定名称）
  ├── build.sh
  ├── davinci.sql           # 完整系统数据库脚本（包含所有补丁）
  ├── initdb.bat            # 针对 Windows 环境的初始化数据库批处理脚本
  ├── initdb.sh             # 针对 Linux、Mac 环境的初始化数据库 Shell 脚本
  ├── phantom.js            # 截图脚本（未来版本将不再使用）
  ├── restart-server.sh     # 针对 Linux、Mac 环境的重启服务脚本
  ├── run.bat               # 针对	Windows 环境的服务启停核心脚本						
  ├── start.bat             # 针对 Windows 环境的服务启动脚本
  ├── start-server.sh       # 针对 Linux、Mac 环境的服务启动脚本
  ├── stop.bat              # 针对 Windows 环境的服务停止脚本
  └── stop-server.sh        # 针对 Linux、Mac 环境的服务停止脚本

用户配置

├── config                          # 用户配置目录
  ├── application.yml.example         # 应用配置模板
  ├── datasource_driver.yml.example   # 自定义数据源配置模板
  └── logback.xml                     # 日志配置

代码目录结构

├── server                                  # Server 代码根目录
   ├── src                                    # 源码
  	  ├── main
  	  	 ├── java
  	  	 	└── edp
  	  	 	   ├── core                             # 核心配置及通用代码
  	  	 	   ├── davinci                          # Davinci 业务代码 
  	  	 	   ├── DavinciServerApplication         # 系统启动类
  	  	 	   └── SwaggerConfiguration             # Swagger 配置类
  	  	 └── resources
  	  	 	├── generator
  	  	 	├── mybatis                           # mybatis mapping 目录
  	  	 	├── templates                         # 邮件、Sql 模板目录 
  	  	 	├── application.yml                   # 系统核心配置文件
  	  	 	└── banner.txt
  	  └── test                                # 测试代码目录
   └── pom.xml                              # Davinci Server maven 配置文件，继承自项目根目录pom.xml

日志目录

├── logs        # 日志根目录
  ├── sys         # 系统日志目录
  └── user        # 用户日志目录
  	 ├── opt        # 用户操作日志
  	 └── sql        # 用户Sql日志
环境变量

配置系统环境变量或 IDE 环境变量 DAVINCI3_HOME，推荐优先使用 IDE 环境变量。

数据库
  1. 自行创建 Davinci 系统数据库；
  2. 修改 bin/initdb.sh 或 bin/initdb.bat 中的数据库相应信息并执行 或 直接在数据库客户端导入 bin/davinci.sql。
配置文件

重命名 config/ 目录下 application.yml.example 文件为 application.yml，并配置相关属性。

打包
  1. 打完整 release 包需要修改根目录下 /assembly/src/main/assembly/assembly.xml 中相关版本信息，然后在根目录下执行: mvn clean package 即可；
  2. 打 server 包可直接在 server/ 目录下执行 mvn clean package。

Pull Request 指引

  • 如果你还不知道怎样向开源项目发起 PR，请参考这篇说明
  • 无论是 Bug 修复，还是新功能开发，请将 PR 提交到 dev-0.3 分支。
  • PR 和提交名称遵循 <type>(<scope>): <subject> 原则，详情可以参考阮一峰的 Commit message 和 Change log 编写指南 这篇文章。
  • 如果 PR 中包含新功能，理应将文档更新包含在本次 PR 中。
  • 如果本次 PR 尚未准备好合并，请在名称头部加上 [WIP] 前缀（WIP = work-in-progress）。
  • 所有提交到 dev-0.3 分支的提交至少需要经过一次 Review 才可以被合并

Review 标准

在贡献代码之前，可以了解一下什么样的提交在 Review 中是受欢迎的。简单来说，如果一项提交能带来尽可能多增益和尽可能少的副作用或风险，那它被合并的几率就越高，Review 的速度也会越快。风险大、价值低的提交是几乎不可能被合并的，并且有可能会被拒绝连 Review 的机会都没有。

增益

  • 修复导致 Bug 的主要原因
  • 添加或修复一个大量用户亟需的功能或问题
  • 简单有效
  • 容易测试，有测试用例
  • 减少复杂度以及代码量
  • 经社区讨论过的、确定需要改进的问题

副作用和风险

  • 仅仅修复 Bug 的表面现象
  • 引入复杂度高的新功能
  • 为满足小众需求添加复杂度
  • 改动稳定的现有API或语义
  • 导致其他功能不能正常运行
  • 添加大量依赖
  • 随意改变依赖版本
  • 一次性提交大量代码或改动

Reviewer 注意事项

  • 请使用建设性语气撰写评论
  • 如果需要提交者进行修改，请明确说明完成此次 Pull Request 所需要修改的所有内容
  • 如果某次 PR 在合并后发现带来了新问题，Reviewer 需要向 PR 作者联系并沟通解决问题；如果无法联系到 PR 作者，Reviewer 需要将此次 PR 进行还原

贡献进阶

关于 Committers（Collaborators）

如何成为 Committer

如果你对 Davinci 代码有过颇具价值的 PR 并且被合并，你可以在这个 Issue 下评论，或是通过官方微信群联系核心开发团队申请成为 Davinci 项目的 Committer；核心开发团队和其他 Committers 将会一起投票决定是否允许你的加入，如果得到足够票数，你将成为 Davinci 项目的 Committer。

Committer 的权利

  • 可以加入官方开发者微信群，参与讨论和制定开发计划
  • 可以对 Issue 进行管理，包括关闭、添加标签
  • 可以创建和管理项目分支，master、dev-0.3、dev-0.2 分支除外
  • 可以对提交到 dev-0.3 分支的 PR 进行 Review
  • 可以申请成为 Committee 成员

关于 Committee

如何成为 Committee 成员

如果你是 Davinci 项目的 Committer，并且你贡献的所有内容得到了其他 Committee 成员的认可，你可以申请成为 Davinci Committee 成员，其他 Committee 成员将会一起投票决定是否允许你的加入，如果全票通过，你将成为 Davinci Committee 成员。

Committee 成员的权利

  • 可以合并其他 Committers 和贡献者提交到 dev-0.3 分支的 PR