Guideline 5.6(Developer Code of Conduct – Review Suspensed 应作 Review Suspended,即审核暂停)大概是最“空”的一类拒审:它不点名任何具体缺陷——没有崩溃、没有缺失的 API、没有要补的元数据字段——只说整体没有达到“有意义、足够打磨、可靠”的分发标准,并且写明了一个日期(这次是 8 月 18 日):在那之前不接受重新提交,提前的回复和重提不会被审理。
遇到它,第一个错误是把它当 bug 报告来读。正确的第一步不是诊断代码,而是读清它给的两条边界:日期和渠道。写明日期的拒绝不是暂态故障,是日程——日期之前提交的任何版本都不可能成功,多试不会让门开;而且要把“被拒绝进场”和“失败的工作”分开计数,否则连续几次提前重提看起来像努力,实际上只是反复撞同一扇关着的门,还可能被读成没有读懂通知。
为什么提交前完全看不见?因为发布前的检查能查的都是可判定的具体缺陷:能不能编译、截图对不对、字段全不全。5.6 衡量的是整体——一个每个功能都“能用”的 app,拼起来仍然可以不够“有意义”。门禁全绿和这条拒审并存并不矛盾:绿的是每一个部分,被衡量的是整体。
修复的顺序本身是承重的: 1. 先接受这不是修一个 bug 能解决的事,放下“用代码改动解决审核暂停”的冲动; 2. 把日期写进日程,窗口期内零重提、零追问; 3. 用窗口期对着通知点名的标准做功课:以第一次打开的用户身份,在支持的最旧设备上从冷启动把核心流程完整走一遍,记下每一处犹豫、占位符、死路——修这些,而不是重跑那些本来就绿的门禁; 4. 窗口打开后,克制地重提一次,附上具体、诚实的改动说明;不要把积压一口气全部推上去——从平台视角,批量重提正是引发暂停的那类行为模式。
一分钟自检:翻出你的提交前检查清单,问哪一项可能因为“整体不够打磨”而失败。如果一项都没有,这份清单量的是构建门,不是审核门——而后者往往要等一封 5.6 才第一次显形。