diff --git a/sig/TC/content/doc/projects/openanolis_anck_custom_feature_review_principles.md b/sig/TC/content/doc/projects/openanolis_anck_custom_feature_review_principles.md
index 03f74f5b5127117921c4818a54fedf90633c3e26..484539c86b8214d0943c9520616c05b47954246e 100644
--- a/sig/TC/content/doc/projects/openanolis_anck_custom_feature_review_principles.md
+++ b/sig/TC/content/doc/projects/openanolis_anck_custom_feature_review_principles.md
@@ -10,8 +10,10 @@
| 有独立 kconfig 开关控制的内核定制 | ANCK 已有相似定制的功能，存在冲突可能性 | 拒绝 | 采用下列决策之一后再评审：
1.找到冲突合并实现方式
2.考虑重新设计
3.原有定制和新定制全部放弃，只在下游衍生版维护 |
| 有独立 kconfig 开关控制的内核定制 | 无冲突的独立模块或源文件，只能在内核实现，具有通用性 | 接受 | 评审过程中必须满足下列条件：
1. 跟其内核其他任何模块/代码是正交关系，不对其他功能有任何影响，且功能特性有通用性。
2. 代码风格满足龙蜥社区的最低要求。
3. 不能有重大稳定性、性能、兼容性问题。
4. 明确maintainer |
| 有独立 kconfig 开关控制的内核定制 | 无冲突的独立模块，只能在内核实现，特性小众独特 | 拒绝 | 采用下列决策之一后再评审：
1.说服生态推广价值或利他价值后再审。
2.以体验功能方式合入（考虑合入 staging 目录，或 kconfig 默认关闭），但合入前需社区 TC 投票决策。
其他必要条件：
1.代码风格满足龙蜥社区的最低要求。
2.不能有重大稳定性、性能、兼容性问题。
3.明确maintainer |
+| 无独立 kconfig 开关控制的内核定制 | kconfig优先，但对于kconfig开关控制过于繁琐的案例，如果有更简洁的开关隔离方法来避免对其他架构平台、功能逻辑造成影响，并有可维护性、稳定性保障的 | 参照有独立 kconfig 开关控制条目评审 | 案例：
1. CPU厂商使用VendorFMS做执行逻辑隔离，并且对比使用kconfig开关，代码更简洁、易维护 |
| 无独立 kconfig 开关控制的内核定制 | \- | 拒绝 | \- |
+
# ANCK Maintainer 制度
推动Cloud Kernel SIG 主产品 ANCK maintainer 制度发展完善。原则上根据社区贡献，逐步吸纳更多的 ANCK 主线的 maintainer，重点考虑几点：