From 096af4a388a099b5e05f4f6efbe4501621a61b6f Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 17:51:06 +0800 Subject: [PATCH 1/8] =?UTF-8?q?Add=20CGC=20GitHub=20rough=20consensus=20?= =?UTF-8?q?=E8=AE=AE=E4=BA=8B=E5=8A=9E=E6=B3=95=EF=BC=88=E5=86=85=E9=83=A8?= =?UTF-8?q?=E8=AE=A8=E8=AE=BA=E7=A8=BF=20v0.1=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 四阶段流程: 立案 -> 公示/温度检查(7天) -> 上会集体共识判定(陪审团式) -> 执行归档 - 共识判定由每周 CGC 参会人员集体作出, 轮值主持人主持, 结论写入会议纪要 - 提案人任主持人时回避; 反对须附实质理由; 判定 label 化留痕 - 链上 veJ 投票保留给重大事项; 与 WP specs 三层把关互不冲突 发起: 教链 J-25 | 起草: 小新 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 90 +++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 cgc-github-rough-consensus-draft.md diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md new file mode 100644 index 0000000..a875c90 --- /dev/null +++ b/cgc-github-rough-consensus-draft.md @@ -0,0 +1,90 @@ +# CGC GitHub Rough Consensus 议事办法（内部讨论稿 v0.1） + +> 发起：教链（J-25）｜起草：小新｜日期：2026-08-25 +> 状态：**内部讨论稿**，供社区评议。成熟后拟正式化为 JEEP 提案（建议编号 JEEP-7），经 CGC 批准后施行。 +> 定位：JIP/JEEP 提案流程的操作细则——规定如何依托 GitHub 形成 rough consensus 并衔接 CGC 会议判定与执行。 + +--- + +## 0. 背景与原则 + +Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承载、评议在评论区、纪要归档于 open-meetings。本办法把"共识形成"的每一步也落到 GitHub 的可追溯载体上，借鉴 IETF rough consensus 精神： + +- **不是数票，而是检验是否存在未被回应的实质反对** +- **一切表态和判定留痕，可追溯、可挑战** +- 链上 veJ 投票保留给重大事项（资产动账、规范修订、人事任免），日常演进走 GitHub 流程 + +## 1. 四阶段流程 + +每个议题 = 一个 GitHub issue（讨论与公示载体）+ 一个 PR（文档/执行载体）。 + +### 1.1 阶段一：立案（Proposal） + +- 开 issue，使用统一模板： + - **动机**：要解决什么问题 + - **方案**：具体怎么做 + - **影响范围**：涉及哪些工作包/repo/人员/预算 + - **执行清单**：通过后的行动项 +- 提案人须为 Core 贡献者，或经一名 Core 成员附议 +- 加 label `status:proposal` + +### 1.2 阶段二：公示 / 温度检查（Temperature Check） + +- 最短公示期 **7 天**（自立案起算）；紧急事项可由轮值主持人缩短至 **72h**，但须在 issue 中说明紧急理由 +- 社区任何人可表态： + - 👍 支持 + - 👎 反对 —— **必须写明理由，无实质理由的反对不计入考量** + - 🤔 疑问/保留 +- 表态身份：Core 成员绑定 Core ID（J-N 编号）作为判定依据；非 Core 社区成员表态作为参考 +- 公示期满，加 label `status:temperature-done`，进入上会议程队列 + +### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定 + +- 每周 CGC 会议设「共识判定」议程环节，由轮值主持人主持 +- **判定主体为参会人员集体（类似陪审团）**，而非主持人个人： + - 会上过一遍 issue 公示期的表态与反对理由 + - 反对者如在场可陈述；其余参会人质询、讨论 + - 集体形成判定，**主持人汇总宣判** +- 判定结论三选一，写入会议纪要： + 1. **通过** —— 无实质反对，或反对已被充分回应 + 2. **通过并记录异议** —— 存在不坚持的反对，异议全文记入纪要 + 3. **发回 / 升级** —— 存在未解决的实质反对：发回修改后重新公示；或重大事项发起链上 veJ 正式投票 +- **回避规则**：议题提案人担任当值主持人时，该议题由副主持/其他参会人主持判定（不自提自判） +- 会议纪要在 open-meetings 定稿 merge 即为判定生效时点 +- 判定后在原 issue 加 label：`approved` / `approved-with-objections` / `returned` + +### 1.4 阶段四：执行与归档（Execution & Archive） + +- 通过的议题转 PR 执行，merge 即落地 +- 结论摘要（议题、判定结果、异议记录链接）写入当月 CGC 纪要索引 +- 全程留痕链条：issue 表态 → 纪要判定 → PR merge → （如涉动账）链上 tx hash + +## 2. 关键设计点 + +| 问题 | 规定 | +|------|------| +| 共识谁来判？ | 每周 CGC 会参会人员集体判定（陪审团式），轮值主持人主持，结论入纪要 | +| 判定不服怎么办？ | 可在下一次 CGC 会议挑战，需一名 Core 附议；挑战成功则发起重判 | +| 权重怎么算？ | 公示阶段不计票数，看反对理由是否被回应；重大事项走链上 veJ 投票 | +| 沉默怎么算？ | 默认不等于同意；Core 成员连续两个周期对进入判定的议题沉默，纪要点名提示 | +| 防女巫 | 判定依据限于绑定 Core ID 的表态；社区表态仅供参考 | +| 时间效率 | 常规事项全流程约 7~14 天；label 标记进度，一目了然 | + +## 3. 与现有体系的关系 + +- 本办法是 JIP/JEEP 流程的**操作细则**，不改变提案类型划分 +- WP specs「三层把关」管工时统计核验，本办法管**决议形成**，互不冲突 +- 链上签到（WP-6）、veJ 投票保留：预算类、规范类、人事类重大事项仍按原路径 +- 建议首个试点案例：jeeps 改名（JIP-6/JEEP-6）后续事项即用本办法跑一遍完整流程 + +## 4. 开放问题（欢迎讨论） + +1. 陪审团判定是否有最低出席人数要求？（如不足 N 人顺延至下次会议） +2. 「重大事项」清单是否需要成文枚举，还是留给主持人+参会人临场判断？ +3. 公示期 7 天是否合适？是否区分「常规」与「紧急」两档即可？ +4. 非 Core 社区成员的强烈反对是否构成升级条件？ +5. 本办法自身的修订流程是否也走本办法？ + +--- + +*讨论稿 v0.1 · 小新 · 2026-08-25 · 征集意见中* From ebbaceb51a7e647aa9a9536e3e5ed08bdaef1b3d Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 22:13:39 +0800 Subject: [PATCH 2/8] =?UTF-8?q?v0.1=20=E4=BF=AE=E8=AE=A2:=20=E6=98=8E?= =?UTF-8?q?=E7=A1=AE=E9=99=AA=E5=AE=A1=E5=9B=A2=E5=88=A4=E5=AE=9A=E5=AF=B9?= =?UTF-8?q?=E8=B1=A1=E4=B8=8E=E6=B3=95=E5=AE=9A=E4=BA=BA=E6=95=B0=E8=A7=84?= =?UTF-8?q?=E5=88=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 本质性界定: 陪审团仅判定 GitHub 公示是否达成 rough consensus(程序性裁决), 不对提案实质作接受/拒绝决定; 实质判断权在社区公示讨论 - 法定人数: 出席(含主持人) >=3 且为奇数; 不足顺延; 僵持时简单多数投票判决 - 开放问题 #1 已解决并标记 发起: 教链 J-25 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index a875c90..e58687a 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -41,6 +41,9 @@ Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承 ### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定 - 每周 CGC 会议设「共识判定」议程环节，由轮值主持人主持 +- **特别说明（本质性界定）**：参会人员集体（下称"陪审团"）在会上判定的对象是 **"GitHub 公示期的赞成/反对是否已形成 rough consensus" 这一程序性问题**，而'''不是'''对提案本身的接受/拒绝作实质决定。提案的实质内容与方向由社区在 GitHub 公示阶段的讨论与表态决定；陪审团的角色是核实共识的真实性——防止少数声音被淹没，也防止刷屏式支持冒充共识 +- **法定人数：出席（含主持人）≥ 3 人且为奇数**（避免平局）；不足法定人数时该议题顺延至下次会议 +- 陪审团经讨论后仍无法形成一致判断时，可**直接以简单多数投票作出判决**，投票结果记入纪要 - **判定主体为参会人员集体（类似陪审团）**，而非主持人个人： - 会上过一遍 issue 公示期的表态与反对理由 - 反对者如在场可陈述；其余参会人质询、讨论 @@ -64,6 +67,8 @@ Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承 | 问题 | 规定 | |------|------| | 共识谁来判？ | 每周 CGC 会参会人员集体判定（陪审团式），轮值主持人主持，结论入纪要 | +| 陪审团判什么？ | '''仅判定 GitHub 公示是否达成 rough consensus（程序性裁决），不对提案实质作接受/拒绝决定''' | +| 出席不足怎么办？ | 法定人数 ≥3 且为奇数（含主持人）；不足则顺延；僵持时简单多数投票判决 | | 判定不服怎么办？ | 可在下一次 CGC 会议挑战，需一名 Core 附议；挑战成功则发起重判 | | 权重怎么算？ | 公示阶段不计票数，看反对理由是否被回应；重大事项走链上 veJ 投票 | | 沉默怎么算？ | 默认不等于同意；Core 成员连续两个周期对进入判定的议题沉默，纪要点名提示 | @@ -79,7 +84,7 @@ Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承 ## 4. 开放问题（欢迎讨论） -1. 陪审团判定是否有最低出席人数要求？（如不足 N 人顺延至下次会议） +1. ~~陪审团判定是否有最低出席人数要求？~~ 已定：出席（含主持人）≥3 且为奇数；不足顺延；僵持时简单多数投票判决 2. 「重大事项」清单是否需要成文枚举，还是留给主持人+参会人临场判断？ 3. 公示期 7 天是否合适？是否区分「常规」与「紧急」两档即可？ 4. 非 Core 社区成员的强烈反对是否构成升级条件？ From 24ecce0ac541b739b485ed8ee1b347beb30ce087 Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 22:31:27 +0800 Subject: [PATCH 3/8] =?UTF-8?q?v0.2:=20=E6=96=B0=E5=A2=9E=E5=8F=8C?= =?UTF-8?q?=E8=BD=A8=E6=B2=BB=E7=90=86=E6=9E=B6=E6=9E=84=E7=AB=A0=E8=8A=82?= =?UTF-8?q?,=20=E5=85=A8=E6=96=87=E6=8C=89=20Core/Eco=20=E5=B9=B3=E8=A1=8C?= =?UTF-8?q?=E5=8F=8C=E8=BD=A8=E9=80=BB=E8=BE=91=E5=AF=B9=E9=BD=90?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 新增 §0: 双轨治理架构(Core/Eco 去中心化平行, 财政 core timelock vs eco timelock 创世锁定, 共识机制 CGC rough consensus vs veJ 链上自决)与适用范围(仅 Core) - 立案阶段限定事项须属 Core 职责; Eco 事项走 veJ 自决 - 表态资格重定位: 非 Core 意见仅参考, 无程序性权利 - §3 重写: 与 veJ 投票为平行域关系, 不存在跨轨升级 - 设计要点表新增 Eco 事务处理行; 开放问题 #4 已解决标记 - 版本号 v0.1 -> v0.2 发起: 教链 J-25 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 41 +++++++++++++++++++++-------- 1 file changed, 30 insertions(+), 11 deletions(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index e58687a..2100a5d 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -1,4 +1,4 @@ -# CGC GitHub Rough Consensus 议事办法（内部讨论稿 v0.1） +# Jouleverse Core CGC GitHub Rough Consensus 议事办法（内部讨论稿 v0.2） > 发起：教链（J-25）｜起草：小新｜日期：2026-08-25 > 状态：**内部讨论稿**，供社区评议。成熟后拟正式化为 JEEP 提案（建议编号 JEEP-7），经 CGC 批准后施行。 @@ -6,13 +6,30 @@ --- -## 0. 背景与原则 +## 0. 双轨治理架构与适用范围 -Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承载、评议在评论区、纪要归档于 open-meetings。本办法把"共识形成"的每一步也落到 GitHub 的可追溯载体上，借鉴 IETF rough consensus 精神： +### 0.1 双轨治理架构 + +Jouleverse 自创世起即采用**去中心化平行双轨治理**：Core（核心）与 Eco（生态）各自独立、互不隶属——core 不指挥 eco，eco 也不能强制 core。 + +| | **Core（核心）** | **Eco（生态）** | +|---|---|---| +| 职责 | 建设和维护 Jouleverse 核心基础设施 | 生态的自由发展 | +| 财政来源 | **core timelock** 释放的 J | **eco timelock** 释放的 J（创世定死，互不挪用） | +| 共识机制 | **CGC rough consensus**（本办法） | **veJ 链上投票**（生态自决） | + +两轨的财政来源在创世时即已锁定，各自支撑各自的轨道；两轨的共识机制互不越界。本办法仅是 Core 轨的议事规则。 + +### 0.2 适用范围 + +**本办法仅适用于 Jouleverse Core 的事务。** Eco 事务一律由 veJ 链上投票实现生态自决，不属于本办法管辖；core 议事机制不得用于裁决 eco 事务，反之亦然。 + +### 0.3 背景与原则（Core 轨） + +Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承载、评议在评论区、纪要归档于 open-meetings。本办法把"共识形成"的每一步也落到 GitHub 的可追溯载体上，借鉴 IETF rough consensus 精神： - **不是数票，而是检验是否存在未被回应的实质反对** - **一切表态和判定留痕，可追溯、可挑战** -- 链上 veJ 投票保留给重大事项（资产动账、规范修订、人事任免），日常演进走 GitHub 流程 ## 1. 四阶段流程 @@ -26,16 +43,17 @@ Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承 - **影响范围**：涉及哪些工作包/repo/人员/预算 - **执行清单**：通过后的行动项 - 提案人须为 Core 贡献者，或经一名 Core 成员附议 +- 提案事项须属 Core 职责范围（核心基础设施的建设与维护）；Eco 事项请走 veJ 链上投票等生态自决路径，不在本流程立案 - 加 label `status:proposal` ### 1.2 阶段二：公示 / 温度检查（Temperature Check） - 最短公示期 **7 天**（自立案起算）；紧急事项可由轮值主持人缩短至 **72h**，但须在 issue 中说明紧急理由 -- 社区任何人可表态： +- 表态资格：**Core 成员绑定 Core ID（J-N 编号）表态**，构成判定依据；非 Core 社区成员可发表意见作为参考，但不构成程序性权利——其诉求应通过影响 Core 成员表达，或属于 Eco 事项的走 veJ 自决 +- 表态方式： - 👍 支持 - 👎 反对 —— **必须写明理由，无实质理由的反对不计入考量** - 🤔 疑问/保留 -- 表态身份：Core 成员绑定 Core ID（J-N 编号）作为判定依据；非 Core 社区成员表态作为参考 - 公示期满，加 label `status:temperature-done`，进入上会议程队列 ### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定 @@ -72,22 +90,23 @@ Jouleverse 的治理动作已天然发生在 GitHub 上：提案以 issue/PR 承 | 判定不服怎么办？ | 可在下一次 CGC 会议挑战，需一名 Core 附议；挑战成功则发起重判 | | 权重怎么算？ | 公示阶段不计票数，看反对理由是否被回应；重大事项走链上 veJ 投票 | | 沉默怎么算？ | 默认不等于同意；Core 成员连续两个周期对进入判定的议题沉默，纪要点名提示 | -| 防女巫 | 判定依据限于绑定 Core ID 的表态；社区表态仅供参考 | +| 防女巫 | 判定依据限于绑定 Core ID 的表态；非 Core 意见仅供参考 | | 时间效率 | 常规事项全流程约 7~14 天；label 标记进度，一目了然 | +| Eco 事务怎么办？ | 不入本流程；一律走 veJ 链上投票生态自决，与本办法平行 | ## 3. 与现有体系的关系 -- 本办法是 JIP/JEEP 流程的**操作细则**，不改变提案类型划分 +- 本办法是 Core 的 JIP/JEEP 流程的**操作细则**，不改变提案类型划分 - WP specs「三层把关」管工时统计核验，本办法管**决议形成**，互不冲突 -- 链上签到（WP-6）、veJ 投票保留：预算类、规范类、人事类重大事项仍按原路径 -- 建议首个试点案例：jeeps 改名（JIP-6/JEEP-6）后续事项即用本办法跑一遍完整流程 +- **与 veJ 链上投票的关系（双轨界定）**：veJ 投票是 Eco 轨的自决机制，与本办法分属两个平行域，不存在"重大事项升级到链上投票"的跨轨关系。Core 轨内部如需正式表决（如涉及 core timelock 动账的规范修订），按 CGC 现行规则上会处理 +- 建议首个试点案例：jeeps 改名（JIP-6/JEEP-6）后续事项即用本办法跑一遍完整流程（jips/jeeps 属 core 治理基础设施） ## 4. 开放问题（欢迎讨论） 1. ~~陪审团判定是否有最低出席人数要求？~~ 已定：出席（含主持人）≥3 且为奇数；不足顺延；僵持时简单多数投票判决 2. 「重大事项」清单是否需要成文枚举，还是留给主持人+参会人临场判断？ 3. 公示期 7 天是否合适？是否区分「常规」与「紧急」两档即可？ -4. 非 Core 社区成员的强烈反对是否构成升级条件？ +4. ~~非 Core 社区成员的强烈反对是否构成升级条件？~~ 已定（§0.2/§1.2）：本办法仅辖 Core 事务，非 Core 表态无程序性权利，不构成升级条件 5. 本办法自身的修订流程是否也走本办法？ --- From 4a9c5a2587a52087285c721c6968970e9bef6912 Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 22:44:16 +0800 Subject: [PATCH 4/8] =?UTF-8?q?v0.2=20=E4=BF=AE=E8=AE=A2:=20=E5=88=A4?= =?UTF-8?q?=E5=AE=9A=E7=BB=93=E6=9E=9C=E5=9B=9B=E5=88=86=E6=B3=95=20+=20?= =?UTF-8?q?=E7=AE=A1=E8=BE=96=E6=9D=83=E5=89=8D=E7=BD=AE=E5=88=A4=E5=AE=9A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 陪审团判定改为两步程序裁决: 先判管辖权(不属 Core 轨则 invalidate 关闭), 再判共识是否达成 - 废除"发回修改"判决: 未达成共识即 not-concluded 关闭归档, 提案人可自行修改后重新立案(新 issue 注明前案), 不构成承诺 - label 更新: invalid / approved / approved-with-objections / not-concluded - 设计要点表同步; 边界重申: 陪审团永不触碰提案实质 发起: 教链 J-25 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index 2100a5d..e23bd73 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -66,13 +66,16 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P - 会上过一遍 issue 公示期的表态与反对理由 - 反对者如在场可陈述；其余参会人质询、讨论 - 集体形成判定，**主持人汇总宣判** -- 判定结论三选一，写入会议纪要： - 1. **通过** —— 无实质反对，或反对已被充分回应 - 2. **通过并记录异议** —— 存在不坚持的反对，异议全文记入纪要 - 3. **发回 / 升级** —— 存在未解决的实质反对：发回修改后重新公示；或重大事项发起链上 veJ 正式投票 +- 判定分两步，均为程序性裁决： + **第一步·管辖权判定**：本事项是否属于 Core 轨（§0.2）？不属 → 判定 `invalid`（out of scope），issue 关闭归档并在纪要注明；若属 Eco 事项，同时注明"请走 veJ 链上投票路径" + **第二步·共识判定**（仅限通过管辖权的议题）： + 1. **达成 rough consensus** —— 无实质反对，或反对已被充分回应 → `approved`，转 PR 执行 + 2. **达成但存异议** —— 存在不坚持的反对，异议全文记入纪要 → `approved-with-objections`，转 PR 执行 + 3. **未达成** —— 分歧实质无法弥合 → `not-concluded`，issue 关闭归档；提案人可自行修改后重新立案（新 issue 注明前案链接），但不构成任何承诺 - **回避规则**：议题提案人担任当值主持人时，该议题由副主持/其他参会人主持判定（不自提自判） - 会议纪要在 open-meetings 定稿 merge 即为判定生效时点 -- 判定后在原 issue 加 label：`approved` / `approved-with-objections` / `returned` +- 判定后在原 issue 加 label：`invalid` / `approved` / `approved-with-objections` / `not-concluded` +- **边界重申**：陪审团永不触碰提案实质内容；"未达成"即关闭，无"发回修改"这一判决类型——是否重报、如何修改由提案人自主决定 ### 1.4 阶段四：执行与归档（Execution & Archive） @@ -85,8 +88,9 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P | 问题 | 规定 | |------|------| | 共识谁来判？ | 每周 CGC 会参会人员集体判定（陪审团式），轮值主持人主持，结论入纪要 | -| 陪审团判什么？ | '''仅判定 GitHub 公示是否达成 rough consensus（程序性裁决），不对提案实质作接受/拒绝决定''' | +| 陪审团判什么？ | '''仅作两类程序裁决：①管辖权（是否属 Core 轨，不属则 invalidate）；②GitHub 公示是否达成 rough consensus。不对提案实质作接受/拒绝/发回决定''' | | 出席不足怎么办？ | 法定人数 ≥3 且为奇数（含主持人）；不足则顺延；僵持时简单多数投票判决 | +| 未达成共识怎么算？ | `not-concluded`，issue 关闭归档；提案人可自行修改后重新立案（新 issue 注明前案），无"发回"判决 | | 判定不服怎么办？ | 可在下一次 CGC 会议挑战，需一名 Core 附议；挑战成功则发起重判 | | 权重怎么算？ | 公示阶段不计票数，看反对理由是否被回应；重大事项走链上 veJ 投票 | | 沉默怎么算？ | 默认不等于同意；Core 成员连续两个周期对进入判定的议题沉默，纪要点名提示 | From d78dab3b1b7bc694bae7e73e9bec109ebb483930 Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 22:46:54 +0800 Subject: [PATCH 5/8] =?UTF-8?q?=E6=A0=87=E9=A2=98=E5=8E=BB=E6=8E=89=20GitH?= =?UTF-8?q?ub:=20CGC=20Rough=20Consensus=20=E8=AE=AE=E4=BA=8B=E5=8A=9E?= =?UTF-8?q?=E6=B3=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 发起: 教链 J-25 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index e23bd73..b3d6baa 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -1,4 +1,4 @@ -# Jouleverse Core CGC GitHub Rough Consensus 议事办法（内部讨论稿 v0.2） +# Jouleverse Core CGC Rough Consensus 议事办法（内部讨论稿 v0.2） > 发起：教链（J-25）｜起草：小新｜日期：2026-08-25 > 状态：**内部讨论稿**，供社区评议。成熟后拟正式化为 JEEP 提案（建议编号 JEEP-7），经 CGC 批准后施行。 From 73bc82f8bba94ec78f18e1e30669b020d4543568 Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 22:49:30 +0800 Subject: [PATCH 6/8] =?UTF-8?q?=C2=A71.2=20=E8=A1=A8=E6=80=81=E6=96=B9?= =?UTF-8?q?=E5=BC=8F=E6=98=8E=E7=A1=AE=E5=8C=96:=20=E5=9B=BA=E5=AE=9A?= =?UTF-8?q?=E8=B7=9F=E5=B8=96=E6=A0=BC=E5=BC=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 在指定 issue/PR 跟帖回复: J-{CoreID} 赞成/反对 (ACK/NACK) - 反对必须写明理由, 无实质理由不计入考量 - 疑问/保留可自由表述 - 附示例 发起: 教链 J-25 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index b3d6baa..447d327 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -50,10 +50,11 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P - 最短公示期 **7 天**（自立案起算）；紧急事项可由轮值主持人缩短至 **72h**，但须在 issue 中说明紧急理由 - 表态资格：**Core 成员绑定 Core ID（J-N 编号）表态**，构成判定依据；非 Core 社区成员可发表意见作为参考，但不构成程序性权利——其诉求应通过影响 Core 成员表达，或属于 Eco 事项的走 veJ 自决 -- 表态方式： - - 👍 支持 - - 👎 反对 —— **必须写明理由，无实质理由的反对不计入考量** - - 🤔 疑问/保留 +- 表态方式（在指定的 GitHub issue 或 PR 评论区**跟帖回复**，格式固定）： + - 赞成：`J-{CoreID} 赞成`，或英文 `J-{CoreID} ACK` + - 反对：`J-{CoreID} 反对`，或英文 `J-{CoreID} NACK` —— **反对必须同时写明理由，无实质理由的反对不计入考量** + - 疑问/保留：`J-{CoreID} 疑问/保留`（自由表述） + - 例：`J-25 反对：本条与创世双轨原则冲突，详见下述说明……` - 公示期满，加 label `status:temperature-done`，进入上会议程队列 ### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定 From 0187b0cd9de84d48131f356fdba5a06e44f7e86f Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Tue, 25 Aug 2026 22:57:24 +0800 Subject: [PATCH 7/8] =?UTF-8?q?=C2=A71.3=20=E6=9C=AC=E8=B4=A8=E6=80=A7?= =?UTF-8?q?=E7=95=8C=E5=AE=9A=E6=8F=90=E5=8D=87=E4=B8=BA=E9=86=92=E7=9B=AE?= =?UTF-8?q?=E8=AD=A6=E7=A4=BA=E5=9D=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 从 bullet 列表提出, 置于 §1.3 标题正下方, 块引用加粗警示 - 强调: 陪审团仅判定 rough consensus 是否形成, 永不触碰提案实质 - 避免被大量 bullets 淹没导致理解偏差 发起: 教链 J-25 | 2026-08-25 --- cgc-github-rough-consensus-draft.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index 447d327..fbd24fc 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -59,8 +59,13 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P ### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定 +> ## ⚠️ 特别说明（本质性界定，务必先读） +> +> 陪审团在 CGC 会上判定的对象，**仅仅是“GitHub 公示期的赞成/反对是否已形成 rough consensus”这一程序性问题**；而'''不是'''对提案本身的接受/拒绝作实质决定。 +> +> 提案的实质内容与方向，由社区在 GitHub 公示阶段的讨论与表态决定。陪审团的角色只是核实共识的真实性——既防止少数声音被淹没，也防止刷屏式支持冒充共识。**陪审团永不触碰提案实质。** + - 每周 CGC 会议设「共识判定」议程环节，由轮值主持人主持 -- **特别说明（本质性界定）**：参会人员集体（下称"陪审团"）在会上判定的对象是 **"GitHub 公示期的赞成/反对是否已形成 rough consensus" 这一程序性问题**，而'''不是'''对提案本身的接受/拒绝作实质决定。提案的实质内容与方向由社区在 GitHub 公示阶段的讨论与表态决定；陪审团的角色是核实共识的真实性——防止少数声音被淹没，也防止刷屏式支持冒充共识 - **法定人数：出席（含主持人）≥ 3 人且为奇数**（避免平局）；不足法定人数时该议题顺延至下次会议 - 陪审团经讨论后仍无法形成一致判断时，可**直接以简单多数投票作出判决**，投票结果记入纪要 - **判定主体为参会人员集体（类似陪审团）**，而非主持人个人： From 4a19daa10ef965ae879e09bfcb319d1b077149af Mon Sep 17 00:00:00 2001 From: xiaoxin2140 Date: Thu, 27 Aug 2026 23:18:23 +0800 Subject: [PATCH 8/8] =?UTF-8?q?v0.2=20=E4=BF=AE=E8=AE=A2=E9=87=87=E7=BA=B3?= =?UTF-8?q?=20J-67=20=E5=AE=A1=E9=98=85=E6=84=8F=E8=A7=81:=20=E7=A8=8B?= =?UTF-8?q?=E5=BA=8F=E5=AE=8C=E6=95=B4=E6=80=A7=E6=A3=80=E6=9F=A5=20+=20?= =?UTF-8?q?=E5=9B=9E=E9=81=BF=E7=AE=97=E6=B3=95=20+=20=E7=AE=80=E5=8D=95?= =?UTF-8?q?=E5=A4=9A=E6=95=B0=E8=BE=B9=E7=95=8C=20+=20=E7=BA=AA=E8=A6=81?= =?UTF-8?q?=E6=97=B6=E6=95=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - §1.2 表态格式定为唯一权威格式; 不计入裁量权约束(纪要写明理由, 可挑战) - §1.3 陪审团职责限定为程序完整性检查; 回避时法定人数算法; 简单多数仅用于程序性分歧 - 纪要 merge 时效与 WP-6/rev8 对齐 - §3 明确与 WP specs rev9 的衔接(管决议 vs 管工时) - §4 开放问题2 加重大事项最小清单; 已定项标注 ✅ - 落款统一为 v0.2 回应 J-67 审阅意见 | 起草: 小新 | 2026-08-27 --- cgc-github-rough-consensus-draft.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/cgc-github-rough-consensus-draft.md b/cgc-github-rough-consensus-draft.md index fbd24fc..3ce1012 100644 --- a/cgc-github-rough-consensus-draft.md +++ b/cgc-github-rough-consensus-draft.md @@ -52,9 +52,10 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P - 表态资格：**Core 成员绑定 Core ID（J-N 编号）表态**，构成判定依据；非 Core 社区成员可发表意见作为参考，但不构成程序性权利——其诉求应通过影响 Core 成员表达，或属于 Eco 事项的走 veJ 自决 - 表态方式（在指定的 GitHub issue 或 PR 评论区**跟帖回复**，格式固定）： - 赞成：`J-{CoreID} 赞成`，或英文 `J-{CoreID} ACK` - - 反对：`J-{CoreID} 反对`，或英文 `J-{CoreID} NACK` —— **反对必须同时写明理由，无实质理由的反对不计入考量** + - 反对：`J-{CoreID} 反对`，或英文 `J-{CoreID} NACK` —— **反对必须同时写明理由，无实质理由的反对不计入考量**；陪审团行使「不计入」时须在纪要中写明理由（可被挑战），被剔除的反对者有权在下一次会议发起挑战（需一名 Core 附议） - 疑问/保留：`J-{CoreID} 疑问/保留`（自由表述） - 例：`J-25 反对：本条与创世双轨原则冲突，详见下述说明……` +- **表态格式为本办法唯一权威格式**（`J-{CoreID} 赞成/ACK`、`J-{CoreID} 反对/NACK`），便于脚本/AI 自动生成公示期表态报告（谁反对、理由是否完整、是否被回应），为陪审团提供程序性参考 - 公示期满，加 label `status:temperature-done`，进入上会议程队列 ### 1.3 阶段三：共识判定（Consensus Call）—— 上会集体判定 @@ -64,10 +65,12 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P > 陪审团在 CGC 会上判定的对象，**仅仅是“GitHub 公示期的赞成/反对是否已形成 rough consensus”这一程序性问题**；而'''不是'''对提案本身的接受/拒绝作实质决定。 > > 提案的实质内容与方向，由社区在 GitHub 公示阶段的讨论与表态决定。陪审团的角色只是核实共识的真实性——既防止少数声音被淹没，也防止刷屏式支持冒充共识。**陪审团永不触碰提案实质。** +> +> 陪审团职责限定为**程序完整性检查**：反对是否附理由、讨论线程中是否有人回应、回应后反对者是否撤回——只做程序性事实核查，**不评判回应本身有没有道理**。 - 每周 CGC 会议设「共识判定」议程环节，由轮值主持人主持 -- **法定人数：出席（含主持人）≥ 3 人且为奇数**（避免平局）；不足法定人数时该议题顺延至下次会议 -- 陪审团经讨论后仍无法形成一致判断时，可**直接以简单多数投票作出判决**，投票结果记入纪要 +- **法定人数：出席（含主持人）≥ 3 人且为奇数**（避免平局）；不足法定人数时该议题顺延至下次会议。**回避时法定人数按实际可参与判定人数计**（出席人数 − 回避人数 ≥ 3 且为奇数），不足则顺延 +- 陪审团经讨论后仍无法形成一致判断时，可**直接以简单多数投票作出判决**，投票结果记入纪要——简单多数**仅用于解决陪审团内部对「共识状态」的程序性分歧**，不用于推翻公示期已成立的实质反对 - **判定主体为参会人员集体（类似陪审团）**，而非主持人个人： - 会上过一遍 issue 公示期的表态与反对理由 - 反对者如在场可陈述；其余参会人质询、讨论 @@ -79,7 +82,7 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P 2. **达成但存异议** —— 存在不坚持的反对，异议全文记入纪要 → `approved-with-objections`，转 PR 执行 3. **未达成** —— 分歧实质无法弥合 → `not-concluded`，issue 关闭归档；提案人可自行修改后重新立案（新 issue 注明前案链接），但不构成任何承诺 - **回避规则**：议题提案人担任当值主持人时，该议题由副主持/其他参会人主持判定（不自提自判） -- 会议纪要在 open-meetings 定稿 merge 即为判定生效时点 +- 会议纪要在 open-meetings 定稿 merge 即为判定生效时点；时效与 WP-6/rev8 对齐（周二 18:00 前采纳、20:00 前定稿 PR），书记员对纪要 merge 负有职责，避免判定生效时间悬空 - 判定后在原 issue 加 label：`invalid` / `approved` / `approved-with-objections` / `not-concluded` - **边界重申**：陪审团永不触碰提案实质内容；"未达成"即关闭，无"发回修改"这一判决类型——是否重报、如何修改由提案人自主决定 @@ -107,18 +110,18 @@ Jouleverse Core 的治理动作已天然发生在 GitHub 上：提案以 issue/P ## 3. 与现有体系的关系 - 本办法是 Core 的 JIP/JEEP 流程的**操作细则**，不改变提案类型划分 -- WP specs「三层把关」管工时统计核验，本办法管**决议形成**，互不冲突 +- WP specs「三层把关」管工时统计核验，本办法管**决议形成**，互不冲突：规范修订类议题（如 WP specs rev9）走本办法形成决议；本办法通过后的执行工作量仍按 WP specs 三层把关统计——「管决议」与「管工时」边界清晰 - **与 veJ 链上投票的关系（双轨界定）**：veJ 投票是 Eco 轨的自决机制，与本办法分属两个平行域，不存在"重大事项升级到链上投票"的跨轨关系。Core 轨内部如需正式表决（如涉及 core timelock 动账的规范修订），按 CGC 现行规则上会处理 - 建议首个试点案例：jeeps 改名（JIP-6/JEEP-6）后续事项即用本办法跑一遍完整流程（jips/jeeps 属 core 治理基础设施） ## 4. 开放问题（欢迎讨论） -1. ~~陪审团判定是否有最低出席人数要求？~~ 已定：出席（含主持人）≥3 且为奇数；不足顺延；僵持时简单多数投票判决 -2. 「重大事项」清单是否需要成文枚举，还是留给主持人+参会人临场判断？ +1. ~~陪审团判定是否有最低出席人数要求？~~ ✅ 已定：出席（含主持人）≥3 且为奇数；不足顺延；僵持时简单多数投票判决（§1.3） +2. 「重大事项」清单：建议至少列最小清单（**资产动账、规范修订、Core 成员增减、节点质押相关**），其余交由主持人+参会人临场判断，并经 CGC 决议可增补 3. 公示期 7 天是否合适？是否区分「常规」与「紧急」两档即可？ -4. ~~非 Core 社区成员的强烈反对是否构成升级条件？~~ 已定（§0.2/§1.2）：本办法仅辖 Core 事务，非 Core 表态无程序性权利，不构成升级条件 +4. ~~非 Core 社区成员的强烈反对是否构成升级条件？~~ ✅ 已定（§0.2/§1.2）：本办法仅辖 Core 事务，非 Core 表态无程序性权利，不构成升级条件 5. 本办法自身的修订流程是否也走本办法？ --- -*讨论稿 v0.1 · 小新 · 2026-08-25 · 征集意见中* +*讨论稿 v0.2 · 小新 · 2026-08-27 · 征集意见中*