Skip to content

Byzer Improvement Proposal (BIP)

hellozepp edited this page Mar 9, 2022 · 6 revisions

什么是 BIP?

BIP 是“Byzer 改进提案”,它是用于提议对 byzer-org 代码库进行更改的机制。这些变化可能是在新功能、大型的代码重构、API 更改方面。

实际上,BIP 定义了一个流程,开发人员可以在该流程中提交设计文档、在社区内建立共识、记录不同意见并让项目可以很好的进行下去。

另外,改进提案也是组织管理中比较常用的计划管理方式之一,在开源组织管理中使用也有广泛的运用,比如:以太坊改进提案(EIP)、Pulsar 改进提案 (PIP)等。

BIP 的目标是什么?

BIP 过程有如下几个目标:

  1. 确保社区对 byzer-org 代码库的重大变更进行技术讨论。

  2. 为 Pull Requests 的更​​改提供清晰而全面的设计文档。确保每个 Byzer 开发人员都有足够的上下文来有效地对 Pull Requests 执行代码审查。

  3. 使用 BIP 文档作为创建新功能的文档基础。

  4. 对影响公共 API 的更改进行更严格的审查,以减少引入破坏性更改或未表达理想语义的 API 的机会。

BIP 的目标并不是增加冗杂繁琐的的流程和减缓开发速度,必要时应该以需求紧急程度和交付质量做为更高的优先级。

什么时候需要 BIP?

  • byzer-lang 中的任何新功能

  • 对公共 API(REST API、插件 API)的任何更改

  • HTTP/JDBC 协议 API 的任何更改

  • 对 byzer-lang CLI 工具 API 的任何更改(例如:新选项)

  • 对现有功能语义的任何更改,即使当前行为是不正确的。

  • 任何涉及多个组件的大型代码更改

什么时候不需要 BIP ?

  • Bug修复

  • 不会影响 API 或语义的简单增强功能

  • 文档更改

  • 网站变更

  • 构建脚本更改(除了:完全重写)

谁可以创建 BIP?

欢迎任何愿意为 Byzer 项目做出贡献的人创建 BIP。

BIP 流程如何运作?

BIP 提案可以处于以下状态:

DRAFT:(可选)这可能用于贡献者协作并就提案的不完整版本寻求反馈。

DISCUSSION:该提案已提交给社区以供反馈和批准。

ACCEPTED:该提案已被 Byzer 项目接受。

REJECTED:该提案未被 Byzer 项目接受。

IMPLEMENTED:提议的更改的实施已经完成。

MERGED: 所有内容都已合并。

该过程按以下方式工作:

  1. 提案的作者将创建一个 GitHub issue,选择 BIP 提案的模板。并在Reviewers中邀请 PMC 成员。

  2. 根据讨论和反馈,作者可能会对提案的文本进行一些更改。

  3. 一旦达成一些共识,将由PMC正式批准该提案。欢迎大家对该提案进行投票,尽管它只对 PMC 成员的投票具有约束力,PR 的 review 需要获得至少2位拥有合并权限的 committer 或者PMC。

  4. 当提案得到批准,提案的状态需要更新为 ACCEPTED,与该提案相关的 Pull Requests 可以开始合并到主分支中。

  5. 创建的所有 Pull Requests 都应始终在提交日志消息和 PR 标题中引用 BIP-XXX。

BIP 的标签

除了当前状态外,BIP 的 GitHub 问题也将使用其他标签进行标记。

BIP示例:

Labels:processing、complete、help wanted、... 针对的 Byzer 版本:2.1.0、2.2.0、...

BIP 设计文档的模板

Status: DISCUSSION
Author: hellozepp
Contributor: hellozepp
Date: 2022.02.24
Issue: #1234
Pull Requests: #1234

## 背景



## 预期收益

定义此提案的范围。 鉴于上述背景,
该提案正在解决的问题是什么。

## 变更点

举例说明对 API 或其他协议的所有变更,核心的类、方法的变更,包括 JavaDoc。

## 技术设计

技术设计是对所有变更点的详细描述。应该体现比较细节的部分,任何熟悉 Byzer 内部结构的开发人员都能够理解该提案的所有代码的变更内容。

这也应该作为任何试图了解或调试某个特性的人使用的文档。


## 兼容性

是否存在兼容性问题,以及如何解决。

## 测试计划

单元测试和集成测试的方案。