2020年1月25日，春节，在这个特殊的日子，我们正式发起了《
wuhan2020：武汉新型冠状病毒防疫开源信息收集平台
》的开源项目，用开发者们的方式支援这场没有硝烟的战争。截至2020年1月28日21时，全国共有4630个确诊病例、73个治愈病例、以及106个死亡病例，海外60个确诊病例，形势异常严峻。
项目之初，我们看到的是，面对突如其来的新型冠状病毒疫情，武汉及周边各市县均爆出物资供给不足的情况，而重大公共卫生事件在公共社会事件中属于较复杂的类型，统筹安排难度大，周期长。而且，目前信息采集与公布平台不一致，信息散乱很难进行有效沟通，大量图片信息不利于实时沟通。
作为开发者群体，我们思考的是能否利用数字平台优势，让各供需方进行分布式自助对接可大幅提升效率。故发起该项目，旨在统一收集本次事件中相关事务处理方的信息，并利用开源和分布式协作优势实时更新并通报，提供各方的联系平台。这里，供需数字化和信息的透明快速扭转是我们认为的关键所在。
事实上已有相似的石墨文档项目发起，保持在 50 人左右的协同编辑热度，但石墨文档编辑的方式，很难保证格式一致性，需要有专人实时对内容格式进行编辑，各种标注较为混乱，而且对于后期加入程序可视化与交互能力并不友好。正好我们又是一群开源爱好者，故直接在 GitHub 上发起了该项目，望众程序员可以齐心协力，共克时艰。
旨在统一收集本次事件中相关事务处理方的信息，并利用开源和分布式协作优势进行实时更新并通报，提供各方联系的综合平台，其核心是通过公开众包的形式进行采集数据，同样通过众包审核后，将带有数据来源的信息合并到代码仓库中，并形成一套完整的流程机制。
在项目初期，其实我们并没有仔细思考整个平台的功能，特别是从产品的角度，这也受限于团队本身。我们首先制定了几件容易想到的事情，包括：
-
-
信息主体：医院信息、酒店信息、物流信息、生产信息、捐赠信息、捐款信息、预防治疗手段、新闻内容等
-
-
-
在项目开始实施后，我们开始遇到了一些问题，同时也总结了部分经验，具体如下。
-
-
网上流传的有些信息被篡改，不知道群里的数据本身是不是被篡改
-
-
-
-
-
-
-
-
流程、流程、流程：流程是规范大家行为，保证每个人的行动一致、结果的偏差小
-
-
-
医院汇总人员直接录入，可信程度最高，同时带上录入员信息
基于上述挑战和经验，我们重新进行了顶层设计，并把中心放在标准的流程和标准的录入规范上面，同时继续用石墨工具进行统一信息采集。这里要重点提一下石墨团队，直接拉了主力开发人员协助我们进行数据接口的对接。探索中，我们逐步形成了如下的协作流程：
持续更新，以Github上的为准
目前我们设计的
《信息协作流程规范》
中，信息流程如下：
石墨表格 --> Git 数据仓库 --> 前端展示
其中，
石墨流程包括：
-
-
-
-
审核人有严格的制度，审核人信息实名落地，保证不会有恶意审核
-
石墨文档中，申请并通过的账号有录入权限，但表头与审核状态列只有审核人可以编辑
-
审核人在审核确定某条记录真实后，会锁定该行，不能再进行编辑
-
对于数据重复校验，使用石墨的重复数据自动高亮功能提示，并提供脚本的定时检查能力
数据落仓包括：
-
-
-
落仓时仅落入已经审核通过的数据，未通过数据不予落仓
-
-
落仓由程序自动化进行，保证数据实时性不会高于 15 分钟的误差
-
-
对于特定行，例如特定医院记录，邀请联系人成为该行数据编辑人，仅能编辑本医院条目，其他类别类似
数据展示包括：
-
-
任何开发者可自行开发可视化展示、检索、分析程序，直接使用线上数仓数据
通过以上流程，
采取分组制，流水线作业
，好处是：
-
-
严格用核心成员保证审核人的来源，保证了数据录入有效性，所有数据必须经过实名审核员审核
-
保证自动化程度，保证后期的大规模水平扩展能力，除数据审核外全流程数据落地全部自动化，无需人工介入
-
保证数据有效性，数据审核后锁定，除数据源负责人，无人可进行修改
-
保证数据时效性：该条需要该平台首先成为唯一数据源平台，则数据源负责人在需求变动时仅需修改表单对应行即可
-
数据是实时变化的，而且由于使用的是 Git 数仓，其实我们可以拿到所有的历史变化记录，便于数据分析工作
基于上述思想，我们形成了
《信息收集录入流程规范》
，录入组必须遵循这样的规范才能录入信息；同样，我们也形成了
《信息审核流程规范》
，审核员也必须按照该规范才能进行数据落仓。
我们希望通过自动化手段来聚集数据，当其成长为主要平台时，各数据源自然会来我们这里发布和修改数据，而我们的
