update tpc team description&repo management-community-AtomGit

Mcangjie_pmc/pmc.md+2-2

	@@ -32,7 +32,7 @@
32	\| Infrastructure Team \| 安全CICD领域竞争力分析和关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等; <br/>负责CICD领域系统设计方案的技术评审，技术决策，模块关键技术问题解决; <br/>负责CICD领域的社区需求技术规划和梳理对应领域的共建需求梳理。\|	32	\| Infrastructure Team \| 安全CICD领域竞争力分析和关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等; <br/>负责CICD领域系统设计方案的技术评审，技术决策，模块关键技术问题解决; <br/>负责CICD领域的社区需求技术规划和梳理对应领域的共建需求梳理。\|
33	\| Document Team \| 文档规划和信息架构设计、文档版本生命周期管理，风格指南等质量保证和标准化规范制定、文档贡献流程建设、文档维护更新、审核文档、响应并处理社区文档问题反馈。\|	33	\| Document Team \| 文档规划和信息架构设计、文档版本生命周期管理，风格指南等质量保证和标准化规范制定、文档贡献流程建设、文档维护更新、审核文档、响应并处理社区文档问题反馈。\|
34	\|InterOp Team\| 负责互操作技术领域的竞争力分析、关键技术识别与突破，主导功能分解、接口定义与维护管理，构建易用、高性能的互操作能力；<br/>主导系统设计方案评审与技术决策，解决关键技术问题，确保技术方案与架构的先进性与可行性；<br/>统筹互操作领域代码开发、维护及质量保障，通过架构设计与代码审核，推动高质量代码合入主干；<br/>规划互操作社区需求技术方案，梳理共建需求，推动开源社区问题闭环与技术方案落地；\|	34	\|InterOp Team\| 负责互操作技术领域的竞争力分析、关键技术识别与突破，主导功能分解、接口定义与维护管理，构建易用、高性能的互操作能力；<br/>主导系统设计方案评审与技术决策，解决关键技术问题，确保技术方案与架构的先进性与可行性；<br/>统筹互操作领域代码开发、维护及质量保障，通过架构设计与代码审核，推动高质量代码合入主干；<br/>规划互操作社区需求技术方案，梳理共建需求，推动开源社区问题闭环与技术方案落地；\|
35	-\|TPC Team\| 三方库技术领域竞争力分析和关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等; <br/>负责三方库领域系统设计方案的技术评审，技术决策，模块关键技术问题解决;<br/>负责三方库技术领域的社区需求技术规划和梳理对应领域的共建需求梳理;<br/>代表三方库技术领域参加仓颉社区的峰会和布道。\|	35	+\|TPC Team\| 承担仓颉精品三方库的开发、维护和管理；为 Cangjie-TPC 组织下项目制定打分、排名和推荐标准，并维护 [Cangjie-TPC 组织首页](https://atomgit.com/cangjie-tpc) "精选项目"板块；<br/>负责 Cangjie-SIG、Cangjie-TPC 组织下仓库建仓申请的审核与管理；<br/>统筹三方库技术领域竞争力分析与关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等;<br/>负责三方库领域系统设计方案的技术评审，技术决策，模块关键技术问题解决;<br/>负责三方库技术领域的社区需求技术规划和梳理对应领域的共建需求梳理;<br/>代表三方库技术领域参加仓颉社区的峰会和布道。<br/>TPC Team Leader 由 PMC 任命，定期向 PMC 汇报工作计划与工作进展。\|
36	\|AIAgent Team\| 负责仓颉面向Agent开发底座能力构建，负责仓颉面向AI Agent领域竞争力分析、关键技术识别与突破；<br/>负责仓颉面向Agent编程Agent DSL设计与实现；<br/>负责Agent开发底座功能开发与实现；<br/>负责Agent领域社区影响力建设；\|	36	\|AIAgent Team\| 负责仓颉面向Agent开发底座能力构建，负责仓颉面向AI Agent领域竞争力分析、关键技术识别与突破；<br/>负责仓颉面向Agent编程Agent DSL设计与实现；<br/>负责Agent开发底座功能开发与实现；<br/>负责Agent领域社区影响力建设；\|
37		37
38		38
	@@ -52,7 +52,7 @@
52	\| 朱凯迪 \| [@Boommmmmm](https://gitcode.com/Boommmmmm) \| PMC成员 \| Multi-platform Team \|	52	\| 朱凯迪 \| [@Boommmmmm](https://gitcode.com/Boommmmmm) \| PMC成员 \| Multi-platform Team \|
53	\| 刘晓莹 \| [@liuxiaoying](https://gitcode.com/gcw_soeAfXvg) \| PMC成员 \| QA Team \|	53	\| 刘晓莹 \| [@liuxiaoying](https://gitcode.com/gcw_soeAfXvg) \| PMC成员 \| QA Team \|
54	\| 刘天瑜/胡彬彬 \| [@BestLeon](https://gitcode.com/bestleon) / [@Gcourage](https://gitcode.com/Gcourage) \| PMC成员 \| Test Team \|	54	\| 刘天瑜/胡彬彬 \| [@BestLeon](https://gitcode.com/bestleon) / [@Gcourage](https://gitcode.com/Gcourage) \| PMC成员 \| Test Team \|
55	-\| 胡晓明/张俊 \| [@l3gi0n](https://gitcode.com/l3gi0n) / [@zjdd](https://gitcode.com/zjdd) \| PMC成员 \| Tools Team \|	55	+\| 张俊/金亦凡 \| [@zjdd](https://gitcode.com/zjdd) / [@jyf219](https://gitcode.com/jyf219) \| PMC成员 \| Tools Team \|
56	\| 周广宇 \| [@Timzhou](https://gitcode.com/Timzhou) \| PMC成员 \| IDE Team \|	56	\| 周广宇 \| [@Timzhou](https://gitcode.com/Timzhou) \| PMC成员 \| IDE Team \|
57	\|李卓远/虞嘉豪 \| [@zhuoyuanli](https://gitcode.com/zhuoyuanli) / [@ChaosJohn](https://gitcode.com/ChaosJohn) \| PMC成员 \| Security Team \|	57	\|李卓远/虞嘉豪 \| [@zhuoyuanli](https://gitcode.com/zhuoyuanli) / [@ChaosJohn](https://gitcode.com/ChaosJohn) \| PMC成员 \| Security Team \|
58	\| 朱艳婷 \| [@amy_mayun](https://gitcode.com/amy_mayun) \| PMC成员 \| Document Team \|	58	\| 朱艳婷 \| [@amy_mayun](https://gitcode.com/amy_mayun) \| PMC成员 \| Document Team \|

Mcangjie_pmc/repo_management.md+32-106

 本规范适用于仓颉社区内所有原生开发的代码仓。对于引入的第三方上游社区仓库，其管理原则应与上游社区保持一致。
++### **3. 组织定位与仓库归属**
++
++仓颉社区根据仓库性质与治理层级，将代码仓统一归口至下列三个 AtomGit 组织承载，建仓申请须首先明确目标归属组织：
++
++- **[Cangjie](https://atomgit.com/Cangjie) 组织**：承载仓颉语言项目管理委员会除 TPC Team 之外的作业仓库、仓颉社区章程和用户论坛仓库，以及持续维护的社区运作相关仓库。
++- **[Cangjie-TPC](https://atomgit.com/Cangjie-TPC) 组织**：承载仓颉三方库、工具等项目，由 TPC Team 负责管理。
++- **[Cangjie-SIG](https://atomgit.com/Cangjie-SIG) 组织**：承载非三方库、工具项目，由 TPC Team 负责管理。
++
++
 ## 二、 代码仓建立与准入<a id="section2"></a>
++### **1. 归口管理与建仓权限**
+-2. **职责明确**：建仓申请须明确仓库的责任团队（Team或社区运营办公室），经 PMC 评审通过后，由授权管理员在 [Cangjie-SIG](https://gitcode.com/Cangjie-SIG) 组织下执行建仓。
+-3. **分级审批准入**：
+-   - **版本主干仓库**：凡进入仓颉语言社区版本的仓库，必须经 PMC 评审后方可建立。
+-   - **非版本主干仓库**：不进入仓颉语言社区版本的仓库，可在 Team 评审通过后先行建立，但须向 PMC 备案并同步。
+-   - **授权原则**：PMC 可根据实际治理需要，在其职权范围内授权仓库评审权限。
++代码仓须归属于特定项目及对应组织。建仓申请路径按目标组织分级行使用例决策权：
++- **Cangjie 组织建仓**：由 PMC 决策。建仓申请应由 Team Leader 向 PMC 提交议题申请，由 PMC 按其建仓模板与流程进行审核和管理。
++- **Cangjie-SIG、Cangjie-TPC 组织建仓**：由 TPC Team 决策。建仓申请由申请者向 TPC Team 提交，由 TPC Team 按其[建仓模板](https://gitcode.com/Cangjie-TPC/TPC-Resource/blob/main/%E3%80%90Cangjie-TPC%E7%A4%BE%E5%8C%BA%E3%80%91%E9%A1%B9%E7%9B%AE%E5%88%9B%E5%BB%BA%E7%94%B3%E8%AF%B7.docx)与流程进行审核和管理。
++### **2. 职责明确**
++建仓申请须明确仓库的责任团队（Team 或社区运营办公室）及目标归属组织，经对应组织评审通过后，通过邮件方式向官方邮箱同步会议纪要，由授权管理员根据会议纪要结论在相应组织下执行建仓：
++- Cangjie 组织仓库经 PMC 评审通过后，由授权管理员在 [Cangjie](https://gitcode.com/Cangjie) 组织下执行建仓。
++- Cangjie-SIG、Cangjie-TPC 组织仓库经 TPC Team 决策通过后，由授权管理员分别在 [Cangjie-SIG](https://gitcode.com/Cangjie-SIG)、[Cangjie-TPC](https://gitcode.com/Cangjie-TPC) 组织下执行建仓。
+-![基础配置](./pictures/基础配置.png)
+-
+-### **2.  分支与 Tag 管理**
+-
+-- **工作流模式**：社区统一采取 Fork 开发工作流，原则上禁止开发者直接在主仓库创建分支。
+-
+-![仓库管理](./pictures/仓库管理.png)
+-
+-- **分支命名策略**：分支命名须具备明确语义，遵循以下正则表达式：`^(feature|bugfix|release)/[a-z0-9.-]+$`。
+-  - **发布分支**：以 `release/v<版本号>` 格式命名。
+-  - **特殊说明**：`dev`（开发）与 `main`（发布）分支不受上述命名正则限制。
+-
+-- **Tag 命名规范**：Tag 须与社区版本号保持一致，遵循语义化版本规则：
+-
+-  - 通用格式：`^v(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-([a-zA-Z0-9-]+))?$`。格式为： v<主版本>.<次版本>.<修订版本>-先行版本号(可选)，示例： `V1.2.3-alpha`。
+-
+-  - 扩展库（stdx）特例：`^v(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*).(0|[1-9]\d*)(?:-([a-zA-Z0-9-]+))?$`，其版本命名风格跟其他工程权限有所差异，采用四位版本号规则。
+-
+-## 四、 开发协作与提交准则
+-
+-### **1. 提交规范（Git Commit）**
+-
+-- **日志标准**：推荐采用“约定式提交”（[Conventional Commits](https://www.conventionalcommits.org/zh-hans/v1.0.0/)）规范。提交信息须通过正则校验：`^(?<type>feat|fix|docs|style|refactor|test|chore|perf|build|ci|revert)(\((?<scope>[\w\-]+)\))?!?:\s(?<description>.{1,72})$`。
+-
+-- **物理限制**：单文件提交体积上限为 100M。
+-
+-- **操作禁令**：严禁执行强制推送（Force Push）操作。
+-
+-![提交设置](./pictures/提交设置.png "Request Config")
+-
+-### **2.  权限控制**
+-
+-代码仓核心角色分为 Developer 与 Committer。
+-
+-- **Developer**：拥有基础的开发协作权限。
+-
+-![Developer权限](./pictures/Developer权限.png "Developer")
+-
+-- **Committer**：拥有代码评审及合入控制权限。
+-
+-![Commiter权限](./pictures/Commiter权限.png "Commiter")
+-
+-- **保护分支**：默认开发分支、发布分支及 LTS 版本分支须设置为保护分支。
+-
+-![保护分支](./pictures/保护分支.png "Protect Branch")
++## 三、 代码仓变更与迁移
++### **1. 仓库变更申请（退休、更名及开源引入）**
++- **评审**：仓库变更评审按目标归属组织分级执行：
++  - Cangjie 组织仓库（含版本主干仓库及社区运作相关仓库）的退休、更名或外部开源软件的引入，须提交 PMC 进行评审。
++  - Cangjie-SIG、Cangjie-TPC 组织仓库的退休、更名或外部开源软件的引入，须提交 TPC Team 进行评审。
++## 四、 执行
++### **1. 申请流程**
++- **申请人发起申请**：其中 Cangjie 组织仓库由 Team Leader 向 PMC 申报议题，通过 PMC 会议评审后执行；Cangjie-SIG、Cangjie-TPC 组织仓库按对应组织的建仓申请模板发送邮件至 [contact@cangjie-lang.net](contact@cangjie-lang.net) 办理。
++* Cangjie 组织模板：暂未公布
++* Cangjie-TPC组织模板：[Cangjie-TPC/TPC-Resource](https://gitcode.com/Cangjie-TPC/TPC-Resource/blob/main/%E3%80%90Cangjie-TPC%E7%A4%BE%E5%8C%BA%E3%80%91%E9%A1%B9%E7%9B%AE%E5%88%9B%E5%BB%BA%E7%94%B3%E8%AF%B7.docx)
++* Cangjie-SIG组织模板：暂未公布
++- **会议评审**：由对应组织进行评审并形成会议纪要
++- **代码仓操作**：将会议纪要同步至 [contact@cangjie-lang.net](contact@cangjie-lang.net) ，由授权管理员在3个工作日内进行相关操作。
++### **2. 联系渠道**
++须统一通过联系[contact@cangjie-lang.net](contact@cangjie-lang.net) 进行确认与后台处理。
+-- **门禁校验**：合入前必须确保相关自动化流水线测试（CI）全部通过。
+-
+-- **协议合规**：所有 PR 必须通过 CLA（贡献者许可协议）校验。
+-
+-![CLA 协议](./pictures/CLA协议.png "CLA")
+-
+-
+-
+-### **2.  合并策略限制**
+-
+-- **合入限制**：严禁“自提自合”（即提交者与合入者为同一人），严禁强制合入。所有合并必须通过 Fork 方式进行。
+-
+-![Pull Request](./pictures/PullRequests设置.png "Pull Request")
+-
+-- **信息保留**：为保留项目原始提交脉络，原则上建议禁止 Squash 合并方式。
+-
+-![Squash](./pictures/Squash合并.png "Squash")
+-
+-- **最小审查**：PR 最终必须由至少一名 Committer 审查通过后方可合入。
+-
+-![PR审查](./pictures/PR审查.png "PR")
+-
+-## 六、 代码仓毕业
+-
+-### **1. 仓库孵化阶段流程**
+-
+-仓颉项目仓库从开源建仓至孵化成熟（毕业），须遵循以下标准阶段：
+-
+-- **新建申请阶段**：详见本文第二部分，[“代码仓建立与准入”](#section2)。
+-- **孵化准入阶段**：详见本文第二部分，[“代码仓建立与准入”](#section2)。
+-- **准出终审阶段**：
+-  - 版本主干仓库：在通过预审后，提交议题至[「QA Team 例会评审」](../team/team_qa/meetings)申请孵化准出评审，须确保所有遗留问题已闭环解决。
+-  - 非版本主干仓库：向所属 Team 提交孵化准出终审议题，须确保所有遗留问题已闭环解决。
+-- **正式准出（毕业）** ：向 [contact@cangjie-lang.net](contact@cangjie-lang.net) 提交最终准出申请，正式完成从孵化态向成熟态的转变，将代码仓迁移至 [Cangjie](https://gitcode.com/Cangjie) / [Cangjie-TPC](https://gitcode.com/Cangjie-TPC) 组织。
+-
+-### **2. 仓库变更申请（新增、退休、更名及开源引入）**
+-
+-- **评审**：凡涉及版本主干仓库的新增、退休、更名或外部开源软件的引入，均须首先提交 PMC 进行专业评审；非版本主干仓库相关操作须在所属 Team 内部处理。
+-
+-- **执行路径**：
+-	- **申请流程**：评审通过后，申请人须根据变更需求发起邮件申请。
+-
+-	- **联系渠道**：新增、退休或更名操作须统一通过联系 [contact@cangjie-lang.net](contact@cangjie-lang.net) 进行确认与后台处理。

Acangjie_pmc/repo_settings.md+89-0

@@ -0,0 +1,89 @@
	1	+## 一、仓库配置与命名规范
	2	+
	3	+### 1. 命名与基础设置
	4	+
	5	+- 命名准则：版本主干仓库原则上采用 `cangjie_` 前缀，使用小写字母命名，单词间以底划线 `_` 分隔。例如：`cangjie_multiplatform_interop`。
	6	+
	7	+- 默认分支：开发分支（默认为 `main`）须设置为默认分支。
	8	+
	9	+- 功能约束：除经 PMC 评审备案的特殊用途外，代码仓原则上取消 Wiki 与安全漏洞反馈模块。文档应通过专门的资料仓管理，安全漏洞须通过官网邮件渠道反馈。
	10	+
	11	+![基础配置](./pictures/基础配置.png)
	12	+
	13	+### 2. 分支与 Tag 管理
	14	+
	15	+- 工作流模式：社区统一采取 Fork 开发工作流，原则上禁止开发者直接在主仓库创建分支。
	16	+
	17	+![仓库管理](./pictures/仓库管理.png)
	18	+
	19	+- 分支命名策略：分支命名须具备明确语义，遵循以下正则表达式：`^(feature\|bugfix\|release)/[a-z0-9.-]+$`。
	20	+ - 发布分支：以 `release/v<版本号>` 格式命名。
	21	+ - 特殊说明：`dev`（开发）与 `main`（发布）分支不受上述命名正则限制。
	22	+
	23	+- Tag 命名规范：Tag 须与社区版本号保持一致，遵循语义化版本规则：
	24	+
	25	+ - 通用格式：`^v(0\|[1-9]\d)\.(0\|[1-9]\d)\.(0\|[1-9]\d*)(?:-([a-zA-Z0-9-]+))?$`。格式为： v<主版本>.<次版本>.<修订版本>-先行版本号(可选)，示例： `V1.2.3-alpha`。
	26	+
	27	+ - 扩展库（stdx）特例：`^v(0\|[1-9]\d)\.(0\|[1-9]\d)\.(0\|[1-9]\d).(0\|[1-9]\d)(?:-([a-zA-Z0-9-]+))?$`，其版本命名风格跟其他工程权限有所差异，采用四位版本号规则。
	28	+
	29	+## 二、开发协作与提交准则
	30	+
	31	+### 1. 提交规范（Git Commit）
	32	+
	33	+- 日志标准：推荐采用“约定式提交”（[Conventional Commits](https://www.conventionalcommits.org/zh-hans/v1.0.0/)）规范。提交信息须通过正则校验：`^(?<type>feat\|fix\|docs\|style\|refactor\|test\|chore\|perf\|build\|ci\|revert)($(?<scope>[\w\-]+)$)?!?:\s(?<description>.{1,72})$`。
	34	+
	35	+- 物理限制：单文件提交体积上限为 100M。
	36	+
	37	+- 操作禁令：严禁执行强制推送（Force Push）操作。
	38	+
	39	+![提交设置](./pictures/提交设置.png "Request Config")
	40	+
	41	+### 2. 权限控制
	42	+
	43	+代码仓核心角色分为 Developer 与 Committer。
	44	+
	45	+- Developer：拥有基础的开发协作权限。
	46	+
	47	+![Developer权限](./pictures/Developer权限.png "Developer")
	48	+
	49	+- Committer：拥有代码评审及合入控制权限。
	50	+
	51	+![Commiter权限](./pictures/Commiter权限.png "Commiter")
	52	+
	53	+- 保护分支：默认开发分支、发布分支及 LTS 版本分支须设置为保护分支。
	54	+
	55	+![保护分支](./pictures/保护分支.png "Protect Branch")
	56	+
	57	+
	58	+
	59	+## 三、合入请求（Pull Request）治理
	60	+
	61	+### 1. PR 合入条件
	62	+
	63	+- 多员检视：每个 PR 至少须有两名评审人（Developer 或 Committer）评审通过。
	64	+
	65	+![合入条件](./pictures/合入条件.png "Merge Request")
	66	+
	67	+- 问题闭环：检视发现的所有意见必须实质性解决，严禁未经确认直接标记为解决。
	68	+
	69	+- 门禁校验：合入前必须确保相关自动化流水线测试（CI）全部通过。
	70	+
	71	+- 协议合规：所有 PR 必须通过 CLA（贡献者许可协议）校验。
	72	+
	73	+![CLA 协议](./pictures/CLA协议.png "CLA")
	74	+
	75	+
	76	+
	77	+### 2. 合并策略限制
	78	+
	79	+- 合入限制：严禁“自提自合”（即提交者与合入者为同一人），严禁强制合入。所有合并必须通过 Fork 方式进行。
	80	+
	81	+![Pull Request](./pictures/PullRequests设置.png "Pull Request")
	82	+
	83	+- 信息保留：为保留项目原始提交脉络，原则上建议禁止 Squash 合并方式。
	84	+
	85	+![Squash](./pictures/Squash合并.png "Squash")
	86	+
	87	+- 最小审查：PR 最终必须由至少一名 Committer 审查通过后方可合入。
	88	+
	89	+![PR审查](./pictures/PR审查.png "PR")

Mcangjie_pmc/team_management.md+7-6

	@@ -2,19 +2,19 @@
2		2
3	## 一、 Team Leader 介绍	3	## 一、 Team Leader 介绍
4		4
5	-Team Leader 是仓颉编程语言开源社区 Team 层面的核心管理者与技术领航者，在社区治理体系中承担承上启下的关键作用。其主要定位与核心职责如下：	5	+Team Leader 是仓颉编程语言开源社区 Team 层面的核心管理者与技术领航者，由 PMC 任命，在社区治理体系中承担承上启下的关键作用。其主要定位与核心职责如下：
6		6
7	-- 角色定位：作为 PMC 与 Team 成员间的桥梁，向上对 PMC 负责以确保技术方向的一致性，向下服务团队以构建高质量的协作氛围。	7	+- 角色定位：作为 PMC 与 Team 成员间的桥梁，由 PMC 任命，向上对 PMC 负责以确保技术方向的一致性，向下服务团队以构建高质量的协作氛围。
8	- 技术驱动：负责制定 Team 技术路线图，驱动关键技术规划的落地与演进。	8	- 技术驱动：负责制定 Team 技术路线图，驱动关键技术规划的落地与演进。
9	- 管理与协同：组织日常治理，维护代码质量标准，优化资源分配，并代表 Team 参与社区跨领域协作。	9	- 管理与协同：组织日常治理，维护代码质量标准，优化资源分配，并代表 Team 参与社区跨领域协作。
10	-- 透明化运营：定期向 PMC 汇报进度，确保团队决策过程与信息的公开透明。	10	+- 透明化运营：定期向 PMC 汇报工作计划与进展，确保团队决策过程与信息的公开透明。
11		11
12	## 二、 Team Leader 行使职权	12	## 二、 Team Leader 行使职权
13		13
14	Team Leader 在所属 Team 范围内行使以下管理与决策职权：	14	Team Leader 在所属 Team 范围内行使以下管理与决策职权：
15		15
16	1. 人事管理权：	16	1. 人事管理权：
17	- - 发起 Team 内部角色（如 Committer、Reviewer 等）的提名。	17	+ - 由 Team Leader 负责组建 Team 成员，发起 Team 内部角色（如 Committer、Reviewer 等）的提名，但 Team 成员的任命须报 PMC 批准。
18	- 组织并主持成员选举流程，评估成员表现并提供成长反馈。	18	- 组织并主持成员选举流程，评估成员表现并提供成长反馈。
19	- 推荐优秀成员晋升至更高贡献等级。	19	- 推荐优秀成员晋升至更高贡献等级。
20	2. 技术决策权：	20	2. 技术决策权：
	@@ -75,8 +75,9 @@ Team Leader 的退出分为“主动退出”与“被动罢免”两种情形
75	- 具备至少 3 名核心成员，能够保证该领域的持续投入与维护。	75	- 具备至少 3 名核心成员，能够保证该领域的持续投入与维护。
76	- 新建流程：	76	- 新建流程：
77	1. 提交提案：发起人向 PMC 提交新建 Team 申请书，内容包括 Team 章程、技术范围、初始成员名单及未来 6 个月的路线图。	77	1. 提交提案：发起人向 PMC 提交新建 Team 申请书，内容包括 Team 章程、技术范围、初始成员名单及未来 6 个月的路线图。
78	- 2. PMC 评审：PMC 对提案的必要性、可行性及资源保障情况进行评审。	78	+ 2. PMC 评审：PMC 对提案的必要性、可行性及资源保障情况进行评审，并任命首任 Team Leader。
79	- 3. 公示与设立：评审通过后在社区公示，无异议后正式设立仓库并授予相关权限。代码仓相关操作详见[仓颉社区代码仓管理细则](./repo_management)	79	+ 3. 成员批准：初始成员名单由 Team Leader 组建，但须报 PMC 批准后方可正式纳入 Team。
		80	+ 4. 公示与设立：评审通过后在社区公示，无异议后正式设立仓库并授予相关权限。代码仓相关操作详见[仓颉社区代码仓管理细则](./repo_management)
80		81
81	### 2、 Team 合并	82	### 2、 Team 合并
82		83

Mteam/README_zh.md+7-34

	@@ -14,19 +14,19 @@ Team 是在PMC指导下，负责坐在项目特定子领域及创新项目的架
14		14
15	每个 Team 均包含以下核心角色：	15	每个 Team 均包含以下核心角色：
16		16
17	-•Team Leader：Team 的负责人，通常由 1-2 名在该领域有深入见解和影响力的专家担任，即Team组长与副组长。	17	+•Team Leader：Team 的负责人，由 PMC 任命，通常由 1-2 名在该领域有深入见解和影响力的专家担任，即Team组长与副组长。
18		18
19	•职责:	19	•职责:
20		20
21	- 负责制定和推动 Team 的技术愿景、目标和路线图。	21	- 负责制定和推动 Team 的技术愿景、目标和路线图。
22	- 召集和主持 Team 例会，引导技术讨论和决策。	22	- 召集和主持 Team 例会，引导技术讨论和决策。
23	- 代表 Team 与 PMC (项目管理委员会) 及其他 Team 进行沟通协调。	23	- 代表 Team 与 PMC (项目管理委员会) 及其他 Team 进行沟通协调。
24	-- 定期向 PMC 和社区汇报 Team 的工作进展、成果与风险。	24	+- 定期向 PMC 汇报工作计划和工作进展，接受社区监督和指导；Team Leader 可向 PMC 申请议题，按需触发 PMC 例会。
25	- 维护 Team 的健康运作，激励和发展社区成员。	25	- 维护 Team 的健康运作，激励和发展社区成员。
26	- 负责 Team 仓库权限和邮件列表等基础设置的管理。	26	- 负责 Team 仓库权限和邮件列表等基础设置的管理。
27	- 组长拥有Team内部技术和管理的最终决策权。	27	- 组长拥有Team内部技术和管理的最终决策权。
28		28
29	-•Committer：Team 的核心贡献者，在特定代码仓库拥有写权限。	29	+•Committer：Team 的核心贡献者，在特定代码仓库拥有写权限。Committer 等 Team 内部核心角色由 Team Leader 提名组建，但须报 PMC 批准后方可正式任命。
30		30
31	•职责:	31	•职责:
32		32
	@@ -35,14 +35,14 @@ Team 是在PMC指导下，负责坐在项目特定子领域及创新项目的架
35	- 协助Leader维护其负责专项部分的代码仓库。	35	- 协助Leader维护其负责专项部分的代码仓库。
36		36
37		37
38	-•Contributor：Team 的核心贡献者，在特定代码仓库拥有写权限。	38	+•Contributor：Team 的核心贡献者，在特定代码仓库拥有写权限。Contributor 等 Team 内部核心角色由 Team Leader 提名组建，但须报 PMC 批准后方可正式任命。
39		39
40	•职责:	40	•职责:
41	- 高质量的完成代码开发，提交工作。	41	- 高质量的完成代码开发，提交工作。
42	- 参与文档编写，问题修复或维护等社区贡献。	42	- 参与文档编写，问题修复或维护等社区贡献。
43	- 指导和帮助新成员融入Team。	43	- 指导和帮助新成员融入Team。
44		44
45	-•Member：所有对 Team 所属领域感兴趣并参与贡献的社区成员。	45	+•Member：所有对 Team 所属领域感兴趣并参与贡献的社区成员。Member 名单由 Team Leader 组建并报 PMC 批准。
46		46
47	•职责:	47	•职责:
48		48
	@@ -82,7 +82,7 @@ Team 的生命周期包括创建申请、运作、变更和终止四个阶段。
82		82
83	•邮件列表：作为官方沟通渠道，用于发布通知、讨论议题和归档决策。无独立邮件列表的 Team 可使用 [ dev@cangjie-lang.net](dev@cangjie-lang.net)。	83	•邮件列表：作为官方沟通渠道，用于发布通知、讨论议题和归档决策。无独立邮件列表的 Team 可使用 [ dev@cangjie-lang.net](dev@cangjie-lang.net)。
84		84
85	- •向 PMC 汇报：Team Leader需定期向 PMC 汇报工作进展，接受社区监督和指导。	85	+ •向 PMC 汇报：Team Leader 需定期向 PMC 汇报工作计划与工作进展，接受社区监督和指导；Team Leader 可向 PMC 申请议题，按需触发 PMC 例会。
86		86
87	### 4.解决争议	87	### 4.解决争议
88	- 项目级争议由Committer讨论，必要时上升到Team Leader(s)决策。	88	- 项目级争议由Committer讨论，必要时上升到Team Leader(s)决策。
	@@ -169,31 +169,4 @@ mv team_template.md team/team_yourteamname/team_yourteamname.md
169		169
170	### 3.仓库管理	170	### 3.仓库管理
171		171
172	-#### 3.1仓颉项目仓库孵化流程	172	+仓库管理请参考[仓颉社区仓库管理](./repo_management.md)
173	-
174	-仓颉项目仓库从开源建仓到孵化成熟，通常需经历以下阶段：
175	-1.新建仓库申请：向架构 Team 提交新建仓库申请议题。
176	-2.孵化准出预审：向架构 Team 提交孵化准出预审议题。
177	-3.孵化准出终审：向 QA Team 提交孵化准出终审议题，解决所有遗留问题后完成准出。
178	-
179	-注意：新建仓库必须配置至少 2 名 Committer 以支持代码交叉检视（cross review）；满足基本合规要求，完成孵化仓目标准出的关联仓的联合构建。
180	-
181	-#### 3.2 仓库新增、退休、更名申请
182	-
183	-1.申请架构 Team 评审：
184	-
185	-- 新增、退休、更名。
186	-- 开源软件引入。
187	-- 提交架构 Team 议题进行评审。
188	-
189	-2.发送申请邮件：架构 Team 评审通过后，根据需求提交建仓申请。
190	-
191	-- 新增仓：联系[contact@cangjie-lang.net](contact@cangjie-lang.net)。
192	-- 仓库退休/更名：联系[contact@cangjie-lang.net](contact@cangjie-lang.net)。
193	-
194	-#### 3.3 仓库孵化准出
195	-
196	-1.申请架构 Team 孵化预审：提交议题。
197	-2.申请质量 Team 孵化准出评审：提交议题。
198	-3.提交仓库孵化准出申请：质量 Team 准出评审通过后，向[contact@cangjie-lang.net](contact@cangjie-lang.net)提交准出申请。
199	-

Mteam/repo_list.md+1-1

	@@ -223,7 +223,7 @@
223	</tr>	223	</tr>
224	<tr>	224	<tr>
225	<td rowspan="1">Tools Team</td>	225	<td rowspan="1">Tools Team</td>
226	- <td rowspan="1"><a href="https://atomgit.com/l3gi0n">@l3gi0n</a> / <a href="https://atomgit.com/zjdd">@zjdd</a></td>	226	+ <td rowspan="1"><a href="https://atomgit.com/zjdd">@zjdd</a> / <a href="https://atomgit.com/jyf219">@jyf219</a></td>
227	<td>Cangjie</td>	227	<td>Cangjie</td>
228	<td><a href="https://atomgit.com/Cangjie/cangjie_tools">cangjie_tools</a></td>	228	<td><a href="https://atomgit.com/Cangjie/cangjie_tools">cangjie_tools</a></td>
229	</tr>	229	</tr>

Mteam/team_tools/team_tools_cn.md+1-1

	@@ -19,7 +19,7 @@
19	## Team成员	19	## Team成员
20		20
21	### Leader	21	### Leader
22	-- 胡晓明[@l3gi0n](https://gitcode.com/l3gi0n) / 张俊[@zjdd](https://gitcode.com/zjdd)	22	+- 张俊[@zjdd](https://gitcode.com/zjdd) / 金亦凡[@jyf219](https://gitcode.com/jyf219)
23		23
24		24
25		25

Mteam/team_tpc/team_tpc_cn.md+39-37

	@@ -1,38 +1,40 @@
1	-# team_tpc	1	+# team_tpc
2	-## TPC Team工作目标和范围	2	+## TPC Team工作目标和范围
3	-	3	+
4	-### 工作目标	4	+### 工作目标
5	-编译器技术领域竞争力分析和关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等。	5	+承担仓颉精品三方库的开发、维护和管理；为 [Cangjie-TPC](https://gitcode.com/Cangjie-TPC) 的项目制定打分、排名和推荐标准，并维护 [Cangjie-TPC 组织首页](https://atomgit.com/cangjie-tpc) "精选项目"板块。
6	-	6	+
7	-### 工作范围	7	+### 工作范围
8	-- 三方库技术领域竞争力分析和关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等;	8	+- 承担仓颉精品三方库的开发、维护和管理；为 Cangjie-TPC 组织下项目制定打分、排名和推荐标准，并维护 [Cangjie-TPC 组织首页](https://atomgit.com/cangjie-tpc) "精选项目"板块；
9	-- 负责三方库领域系统设计方案的技术评审，技术决策，模块关键技术问题解决;	9	+- 负责 Cangjie-SIG、Cangjie-TPC 组织下仓库建仓申请的审核与管理；
10	-- 负责三方库技术领域的社区需求技术规划和梳理对应领域的共建需求梳理;	10	+- 统筹三方库技术领域竞争力分析与关键技术识别，功能分解分配，模块间接口定义与维护管理，对应领域特性代码开发维护等;
11	-- 代表三方库技术领域参加仓颉社区的峰会和布道。	11	+- 负责三方库领域系统设计方案的技术评审，技术决策，模块关键技术问题解决;
12	-	12	+- 负责三方库技术领域的社区需求技术规划和梳理对应领域的共建需求梳理;
13	-	13	+- 代表三方库技术领域参加仓颉社区的峰会和布道。
14	-	14	+
15	-### 工作交付件及工作计划	15	+
16	-	16	+
17	-	17	+### 工作交付件及工作计划
18	-	18	+
19	-## Team成员	19	+
20	-	20	+
21	-### Leader	21	+## Team成员
22	-- 夏松[@xdst](https://gitcode.com/xdst)	22	+
23	-	23	+### Leader
24	-	24	+- 夏松[@xdst](https://gitcode.com/xdst)
25	-	25	+
26	-	26	+
27	-### 会议	27	+
28	-- 会议时间：每周五 16:30	28	+
29	-- 会议申报：[Team_TPC Meeting Proposal](https://gitcode.com/Cangjie/community/blob/main/team/team_tpc/meetings/meeting-notices.md)	29	+### 会议
30	-- 会议链接: Welink	30	+- 会议时间：每周一 09:10
31	-- 会议通知: 请[订阅](https://cangjie-lang.cn/pages/maillist)邮件列表 [dev@cangjie-lang.net ](mailto:dev@cangjie-lang.net) 获取会议链接	31	+- 会议申报：[Team_TPC Meeting Proposal](https://gitcode.com/Cangjie/community/blob/main/team/team_tpc/meetings/meeting-notices.md)
32	-- 会议纪要：[查看历史会议纪要](https://gitcode.com/Cangjie/community/blob/main/team/team_tpc/meetings/)	32	+- 会议链接: Welink
33	-	33	+- 会议通知: 请[订阅](https://cangjie-lang.cn/pages/maillist)邮件列表 [dev@cangjie-lang.net ](mailto:dev@cangjie-lang.net) 获取会议链接
34	-	34	+- 会议纪要：[查看历史会议纪要](https://gitcode.com/Cangjie/community/blob/main/team/team_tpc/meetings/)
35	-	35	+
36	-### 联系方式	36	+
37	-	37	+
		38	+### 联系方式
		39	+
38	- 邮件列表： dev@cangjie-lang.cn	40	- 邮件列表： dev@cangjie-lang.cn