圈木云科技
首页
  • 快速开始

    • k8s环境搭建
    • golang微服务版本
    • php环境搭建
    • vue前端技术说明
    • uniapp混合开发介绍
    • 压测报告
    • 错误代码
  • IM服务

    • 简介
    • 快速开始
    • 错误代码
  • 流媒体服务

    • 简介
    • 快速开始
    • 错误代码
教程
  • 01.直播app演示
  • 02.陪玩语聊app演示
  • 03.IM聊天交友app演示
  • php接口文档
  • golang接口文档
  • IM接口文档
  • 流媒体接口文档
  • 源站接口文档
  • 问题反馈
  • 项目问题
  • 异常问题
  • 功能问题
  • 名词解释
  • 关于
  • 谁在用
  • 捐赠列表
  • 更新记录
GitHub (opens new window)

qmcloud

首页
  • 快速开始

    • k8s环境搭建
    • golang微服务版本
    • php环境搭建
    • vue前端技术说明
    • uniapp混合开发介绍
    • 压测报告
    • 错误代码
  • IM服务

    • 简介
    • 快速开始
    • 错误代码
  • 流媒体服务

    • 简介
    • 快速开始
    • 错误代码
教程
  • 01.直播app演示
  • 02.陪玩语聊app演示
  • 03.IM聊天交友app演示
  • php接口文档
  • golang接口文档
  • IM接口文档
  • 流媒体接口文档
  • 源站接口文档
  • 问题反馈
  • 项目问题
  • 异常问题
  • 功能问题
  • 名词解释
  • 关于
  • 谁在用
  • 捐赠列表
  • 更新记录
GitHub (opens new window)
  • 数据看板
  • 贡献指南
    • 可以贡献哪些内容?
    • Issue 规范
    • Pull Request(PR)规范
    • Git Commit 规范
    • 编码规范
    • golangDoc 注释规范
    • 其他
  • 行为准则
  • 用户权益
  • 贡献者们
目录

贡献指南

提示

找一帮你喜欢的、真正靠谱的人,一起做有意思的事

首先,感谢你抽出宝贵的时间参与到(或者有意向参与到) 该项目的贡献!

圈木云直播开源版本 是一款开源的直播解决方案,基于golang微服务设计,分布式IM部署,自研流媒体服务 ,k8s集群管理等应用提供一套标准的技术解决方案,开发者可以基于该项目二次开发等。

圈木云直播开源版本 的成长离不开大家的支持,如果你愿意为该项目贡献代码或提供建议,请阅读以下内容。

# 可以贡献哪些内容?

你可以对以下内容(不仅限于此)进行贡献:

  • 修复bug(已打开的 Issue(gitee issues (opens new window) | github issues (opens new window)) 或者是你发现的 BUG)
  • 完善代码注释
  • 添加单元测试
  • 代码逻辑优化
  • 新功能开发
  • 编写/翻译文档
  • 本文档站中出现的问题
  • 本文档站需要完善的内容
  • 对本文档站的建议
  • 参与问卷调查:
    • [问卷调查]
    • [意见/建议/反馈]
    • [使用者信息登记]
    • [相关文章投稿]
    • [技术文档错误反馈]

代码贡献须知

在你提交代码时请确定你所贡献的代码不存在协议冲突/不兼容的情况

你可以从以下两个方面检查你的代码:

  • 是否新增了第三方依赖库?如果新增了第三方依赖库,其 LICENSE 是否兼容 LGPL-3.0? (LICENSE 兼容,请参考:开源许可证兼容性指南 - 使用库的兼容性列表 (opens new window))
  • 是否参考/借鉴/复制了其他开源项目的代码?被引用的代码所属项目的 LICENSE 是否兼容 LGPL-3.0?(LICENSE 兼容,请参考:开源许可证兼容性指南 - 合并/修改代码的许可证兼容性列表 (opens new window))

如果你的代码或者代码中新引入的依赖项与 LGPL-3.0 不兼容,非常抱歉,我们可能不会合并你的代码。

# Issue 规范

  • issue 仅用于提交 Bug 或 Feature 以及功能相关的内容,其它内容可能会被直接关闭。
  • 在提交 issue 之前,请搜索相关内容是否已被提出,请不要提交重复的问题。
  • 在提交 issue 时,请使用准确的、有实际意义的内容作为标题和描述,方便我们准确定位问题。
  • 在提交 issue 时,请说明 JAP 的版本号,并提供相关异常栈详细截图(请勿截取自以为“很关键”的某段说明,务必截取全部内容)

如何反馈一个高质量的问题?

  • 提供问题的清晰描述,描述具体缺失、过时、错误的内容或者需要改进的文字。
  • 解释该问题对用户的影响。
  • 将给定问题的范围限定在一个具体内容、任务。如果问题牵涉的领域较大,可以将其分解为多个小一点的问题。例如:"文档需要优化" 是一个过于宽泛的问题,而 "XX开发指南缺少对XXX步骤的介绍" 就是一个足够具体的、可操作的问题。
  • 搜索现有问题的列表(gitee issues (opens new window) | github issues (opens new window),查看是否已经有相关的或者类似的问题已被记录。
  • 如果新问题与某其他问题或 PR 有关联,可以使用其完整 URL 或带 # 字符的 PR 编号 来引用它。

如何在社群中高效提问?

  • 社群(QQ群、微信群、Gitter等)中消息比较多而杂,为了更好的解决你的问题,我们建议优先选择 issue(gitee issues (opens new window) | github issues (opens new window)
  • 在社群中提问时尽量采用完整、清晰的描述,不建议此类问题,比如:“xx怎么用?”、“为什么我的报错?”、或者直接发一张异常截图不加描述,对于此类问题,我们可能会选择忽略。
  • 提问前推荐阅读 《提问的智慧》 (opens new window)、《如何向开源社区提问题》 (opens new window) 和 《如何有效地报告 Bug》 (opens new window)、《如何向开源项目提交无法解答的问题》 (opens new window),更好的问题更容易获得帮助。

# Pull Request(PR)规范

  • 请先 fork 一份源码到自己的名下,建立 Fork 分支,不要直接在仓库下建分支。
  • 将 Fork 后的分支 clone 到本地。git clone xxx。
  • 在本地添加/修改代码,完成后将代码 push 到 fork 分支。
  • 在项目中建立 Pull Request,根据平台提示进行提交。注意:pr 请提交到 dev 分支。
  • 等待合并

Pull Request 须知

  • 提交 PR 前,请务必对自己的代码进行格式化。
  • 提交 PR 前请 rebase,确保 commit 记录的整洁。
  • 提交 PR 前请先对代码进行 review。
  • 确保 PR 是提交到 dev 分支,而不是 master 分支。如果你提交的 PR 许久未合并,请确认你是否将 PR 提到了其他分支。
  • 如果是修复未公开的 bug,请在 PR 中给出描述信息,参考:A Note About Git Commit Messages (opens new window)。
  • 如果是修复已存在的 issue,请在描述中引用原文,例如: “Resolves #issueid”。

# Git Commit 规范

  • 请使用英文描述
  • commit 信息要以 类型: [模块名] 描述信息 的形式填写,例如 feat: [qmy-social] add xx feature,”类型“可选如下:
    • refactor:重构
    • feat:新功能
    • docs:文档
    • test:测试
    • fix:bug/issue
    • change:修改
  • commit 完成后,将代码 push 到 fork 分支
  • 请使用具有真实含义的内容
  • 请确保单次 “message” 的内容尽量不超过 100 字
  • 你可以在提交时使用 emoji 表情,使用方式参考:gitmoji (opens new window) | Emoji Cheat Sheet (opens new window)
  • 参考:A Note About Git Commit Messages (opens new window)

# 编码规范

  • 关于包名,请以拥有实际含义的名字命名,不可使用无意义的字母排列或者中文拼音。
    • 新模块务必以com.qmy.jap.模块名 命名,比如:com.qmy.cloud.social。
    • 新业务包务必以com.qmy.jap.模块名.相关业务 命名,比如:com.qmy.cloud.social.config。
  • 关于类名,请以拥有实际含义的名字命名,不可使用无意义的字母排列或者中文拼音。
  • 关于方法名,请以拥有实际含义的名字命名,不可使用无意义的字母排列或者中文拼音。
  • 关于注释,对于简单的方法,可以不添加注释,对于存在复杂逻辑或者有必要强调说明的方法、参数,必须添加注释,注释必须做到精简、准确。
  • 关于文档,我们这不是论文,所以请使用简单、干练或通俗易懂的文案,尽量不要使用大量的专业名词进行堆砌,加大开发者的阅读理解难度。
  • 其他代码规范,请遵循阿里巴巴编码规约。

# golangDoc 注释规范

  • 对于有必要书写 doc 的方法、类、参数,请描述清晰。
  • 如果对方法添加了注释,请务必对方法的参数、返回值、异常等进行解释描述。

# 其他

  • 编写完代码后,请自行格式化代码。
  • 如果是修改的已有文件,请单独格式化自己修改的内容。不要随便格式化其他已经完成的源文件
Last Updated: 2024/04/27, 16:23:31
数据看板
行为准则

← 数据看板 行为准则→

Theme by Vdoing | Copyright © 2022-2025 Copyright © 2021-2040 Quanmu. All rights reserved. 圈木云科技 | 琼ICP备2022006049号
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式