先明确要核验的主张
“社区发展”可能指参与者增加、开发协作持续、治理讨论活跃或协议升级推进。这些主张需要不同证据。开发流程说明可以解释如何参与，但不足以证明参与人数正在增长；一项提案获得讨论，也不足以证明它已经实施。核验时应先把宽泛评价拆成可以检查的具体陈述。
两个来源分别能说明什么
以太坊治理说明（https://ethereum.org/governance/）介绍协议层的链下治理，以及提案、讨论、实现和升级激活之间的关系，并强调社区共识不能用单一指标衡量。它适合支持治理机制的解释，不能单独证明某项提案当前已获认可。
比特币开发说明（https://bitcoin.org/en/development）介绍代码贡献、审查、测试和文档等参与方式，并列出代码仓库与开发讨论渠道。它适合说明开发协作的入口，但贡献者名单或提交次数本身不足以证明整个社区的增长情况。
沿着原始记录核对状态
核验具体事件时，应从介绍页面继续追溯对应的提案文本、讨论记录、代码变更和发布说明。记录标题、作者或维护主体、版本及时间，让结论能够定位到具体证据。对于升级，还需要区分计划、测试与实际激活。
不同记录回答不同问题：讨论可以说明有人提出意见，代码审查可以说明变更受到检查，发布说明可以说明版本包含哪些改动。只有证据覆盖了所声称的阶段，才能使用相应表述，不能把流程中的前一步写成最终结果。
交叉验证要看独立性与统计口径
两个不同网站不一定构成独立佐证，它们可能转载同一公告。交叉验证应检查信息是否来自不同记录，以及是否指向同一事件、同一版本和同一时间范围。以太坊与比特币的说明涉及不同项目，可用于比较协作机制，不能相互证明对方社区的具体进展。
涉及人数或活跃度时，应说明统计范围、观察期间和去重方式。提交次数、讨论数量和参与人数含义不同；如果统计口径不一致，就不宜直接比较，更不能据此推出整体社区更健康。
适用条件与常见问题
这套方法适用于有公开提案、仓库或讨论档案的社区。遇到记录缺失、正文截断或日期不明，应把结论限制在能够追溯的部分。页面页脚年份不能替代内容更新时间。
网站上的说明是否足够？解释基础机制时可以作为依据，核验具体进展时仍需对应记录。讨论热烈是否代表形成共识？还要查看异议、后续处理和实施状态。资料互相冲突怎么办？先检查时间、版本和讨论对象是否一致，无法消除的差异应保留说明。