何谓"英雄榜"？

废话不多说，不扯那些所谓的"进步贡献者荣誉感"、"让奉献被所有人看到"，间接上图！

这就是"排场"，这就是"体面"，这就是"英雄榜"！

  • 感激咱们的设计，设计出如此有质感的页面，丑陋！
  • 感激咱们的前端，完满实现了页面设计，而且反对动静增加徽章类型，优雅！

本文导读

概要

次要分为两大部分，第一局部是 DevStream 英雄榜的简略介绍，第二局部是对 DevStream 的贡献者、证书管理体系及自动化的介绍。

适宜的浏览群体
  • 开源社区运营者：文中具体地介绍了 DevStream 对贡献者信息管理、证书发放等内容的摸索心路，以及是如何实现近乎全自动化的。心愿能给开源社区的经营工作者们带来些启发，尽量减少无意义的重复性工作。
  • 编程爱好者们：自动化流程的实现思路（飞书多维表格、GitHub Actions、脚本等），以及实现技术细节的思考，或者你会感兴趣。附有 GitHub 仓库链接。
  • DevStream 的社区搭档们：这里是咱们的主场——英雄榜！

英雄榜介绍

谁能上榜?

所有取得过证书的 DevStream 的贡献者们。

DevStream 目前共有开源贡献者、布道师、演说家、TopN几大类证书（徽章），每种证书的每个细分类型都应用一个独自的页面来展现贡献者们。

英雄榜的组成

英雄榜次要由证书的图标、介绍、贡献者阵列组成。

实时展现每个"英雄"的 GitHub 头像，点击能够跳转到 Credly 证书页面以校验。

DevStream 的贡献者、证书管理体系介绍

视频版

倡议先看视频一睹为快，再看文章理解整个自动化体系的倒退历程、设计思路、技术细节。

点击图片观看演示与解说视频：

缘起

DevStream 的贡献者证书管理体系来源于一个很不起眼的需要。

五月份左右的时候，DevStream 处于新贡献者的暴发期，简直天天有新贡献者退出。咱们筹备了很多 "good first issue", 往往一呈现就被一抢而空。

随着贡献者越来越多，咱们须要判断某 GitHub 用户是否曾经成为了贡献者，以避免 "good first issue" 的反复申领。

这时候只须要一个简略的表格就能实现。

新证书体系

随着 DevStream 推出新的证书体系，咱们有了十多种细分证书，而且一位贡献者能够被授予多个证书。

每个证书都有其编号、颁发日期、礼物发放细节，传统的单表格模式已无奈满足新的需要。

贡献者与证书治理表格设计

咱们基于飞书多维表格来实现了简单的需要实现，将个人信息与证书颁布信息拆分成两个表格，二者采纳多对多的关联模式。

应用形式：
  1. 填写新贡献者根本信息：在个人信息表注销名字、微信、GitHub等信息不便分割；
  2. 颁发证书：在证书表里把这个人关联进来，并补充颁发日期等信息即可。

以下为操作演示，假如咱们要给"张三"颁布"Talented-Speaker Professional"证书，可在10秒内实现：

快捷视图

在观看演示的时候，你可能会发现，屏幕左侧有十分多的"表"。

其实那些都只是"视图"，即设定不同的统计策略、筛选规定、排序形式，主动渲染，以不同的数据维度展现进去。

上面列举一些罕用的视图：

  1. 每月新增贡献者。主动统计每月新增的贡献者。取得过一次证书即视为贡献者，若屡次取得证书，自动识别第一次取得证书工夫。

  1. 每月新增证书。证书维度的每月新增统计。

  1. 统计面板。以饼图、条形图等形式展示统计数据。

  1. 是否是贡献者。自动检索注销的所有人员信息，取得过一次证书即视为贡献者。用来避免 "good first issue" 的反复申领。

  1. 证书分组。按类型分组展现所有证书。

  1. 单证书视图。只展现某特定类型的证书，如这里只展现 "Contributor - Professional" 类型的证书的颁发状况。

  1. 礼物未寄送。筛选出颁布了证书但未寄送礼物，每个人的每种证书，礼物发放记录是互相独立的。

自动化信息收集

传统经营模式下，贡献者信息表格只能由内部人员编辑，须要应用社交媒体收集了贡献者的信息后，再将信息复制到表格中。沟通过程是"同步"的，老本很高。

DevStream 利用了多维表格的"表单视图"，依据表格的字段主动生成表单。将表单发送给"准贡献者"，填写结束后信息主动保留到表格中。

同时，咱们还通过飞书的"自动化"性能，配置了音讯揭示。每当有贡献者提交了表单，飞书会主动揭示经营人员，不须要再重复询问或确认是否实现了表单的填写，采纳异步沟通的模式进步了效率。

接下来就是颁发 Credly 证书，这部分参照 Credly 官网教程即可。

以上的多维表格，曾经整顿成了模板，能够一键应用：开源社区贡献者与证书治理-模板。

信息同步与自动化

信息同步

原先咱们只有外部的贡献者信息和证书信息管理表格，前面又有了 Credly 证书，当初又有了那么酷炫的英雄榜，以及须要能从英雄榜跳转到特定的 Credly 证书验证页。

加上之前的证书公布状态治理、礼物寄送状态治理，须要一个自动化且可信的数据处理、同步机制。

DevStream 借用了 Single Source of Truth 的理念，将证书表格作为惟一的、规范的信息起源。各种信息的治理和记录都在表格上进行，Credly 颁发实现后证书链接也先填回表格，再导出到官网英雄榜。

自动化

多维表格是"表格“模式，能够导出成 csv 格局； 而DevStream官网仓库渲染英雄榜贡献者应用的格局是 json。

还有很多细节，如：

  1. 表格收集的是中文姓名，官网英雄榜展现的是英文名。
  2. 局部贡献者心愿用本人的英文名而不是中文拼音来展现。
  3. 英雄榜会展现头像，表格里没有相应字段（能够应用 GitHub ID 获取 GitHub 头像）。
  4. Credly 治理页面复制失去的证书链接须要登录能力查看，须要进行格局转换。

DevStream 做了个数据格式转换仓库, 读入 csv 数据，转换成英雄榜须要的 json 数据，并解决中文转拼音等细节。

于是，咱们的操作流程就变成了这样：

  1. 更新完贡献者与证书表格，把飞书表格以 csv 格局下载至本地，并将其挪动到数据转化代码的相应目录中；
  2. 运行程序，主动执行数据格式转换，失去官网英雄榜须要 json 格局；
  3. 应用失去的 json 文件笼罩官网仓库的对应文件；
  4. git add && git commit && git push；
  5. 提 pr 至官网仓库；
  6. review && merge pr。
能不能再简化一些呢？尤其是每次手动提要点开 GitHub 网页提交 pr 好麻烦！

当然能够！—— 我认为绝大多数反复的、可被准确定义或形容的操作，都能够应用代码自动化。

咱们能够应用 GitHub Actions 来实现局部自动化，每次提交最新的含有贡献者和证书信息的 csv 文件，由 Actions 实现"程序运行（数据处理）、复制 json 至官网仓库、提 pr 到官网仓库"的操作。

而后流程就变成了：

  1. 更新表格，下载成 csv ，挪动到相应目录；
  2. git add && git commit && git push （之后由 GitHub Actions 主动执行程序，复制 json、提 pr 到官网仓库）；
  3. review && merge pr。
还能再简略点吗？我只想点点鼠标！

当然！能够！

第二步曾经把执行的命令都写进去了，为什么不间接放到 shell 脚本里？

第一步呢？"下载表格成 csv"本就是个鼠标操作，"挪动到代码目录" 不就是个 mv 吗？

（具体的 GitHub Actions 工作流定义和 shell 脚本，后面的数据格式转换仓库中均已给出）。

最终流程

当贡献者或证书信息更新后：

  1. 鼠标点一下飞书多维表格页的 "下载为 csv"
  2. 鼠标点一下桌面的脚本

泡杯茶，等半分钟，告诉 website 仓库管理员 review pr 并 merge。

一些自动化的探讨

自动化环节，很多中央能够做得更好，以及很多中央是屡次衡量过的后果，简略分享一下：

Q1. 为什么最初还要人工 review？

其实实践上能做到间接合并不须要 review，但最初人工校验一下更平安。

Q2. 为什么最初要依附脚本来在本地操作 Git，而不是建个 web 服务器？

尽管这样看起来很美妙，而且所有人都能很简略地操作且没有任何环境依赖。

同时飞书的多维表格的自动化是反对在表格变动了之后发送 http 申请的，实践上齐全能够做到在表格变动之后，告诉后端服务，被动拉取表格数据、渲染、pr 。

但这样有以下几个问题：

  1. 须要一个服务器，耗费资源，以及本人建的 web 服务器的稳定性大概率不如 GitHub Actions 稳固。
  2. 没有必要去为了这一个小性能去申请一个飞书机器人，而后设置简单的登录逻辑。得失相当。

其实建不建 web 服务器，很大水平取决于如何从飞书端获取导出的数据。DevStream 采纳了"推"的形式被动将数据发送给程序，而不是应用"拉"的形式由程序来申请飞书，尽管后者实践上更安全可靠等，然而实际操作起来会更麻烦。

目前这套流程最终也只须要点两次鼠标就能实现，操作上曾经简直达到最简。

Q3. 文件的安全性如何保障？

目前贡献者敏感信息次要是手机号、微信、收货地址等。

我采取的形式是建个新视图 ——"下载专用（脱敏）"，屏蔽所有敏感信息，只展现渲染英雄榜须要的要害信息。之后下载 csv 都从这个视图里下。
（这就是写博客输入的益处了，建设新视图来屏蔽敏感信息的形式是输入的过程中想到的）。

也能够采取以下形式，更保险：

  • 仓库公有
  • 将下载下来的带有敏感信息的 csv 文件上传到可信的或自建的文件存储服务器，而后在 GitHub Actions 外面下载，同时将网络文件存储服务的明码存至仓库的 Secret 中。
  • 批改局部逻辑，在本地执行 csv 到 json 的转换，GitHub Action 只实现 pr 操作。

一些经营上的想法

写着写着，想到了博客以外的一些内容，想分享一下。

为什么会有这篇博客，或者说，为什么会有这个自动化零碎？

前段时间 DevStream 的全职经营到职，所以咱们进行了一个十分大胆的翻新：每个开发都分担一部分经营的工作。

原以为这会成为开发的一个累赘，但运作到当初，事件变得有意思了起来：

搞技术的人天生受不了重复性的操作，如果让搞技术的来做经营，那么咱们会千方百计地去简化整个流程，进步整体的效率。

所以，对于一个无技术背景的经营来说，治理这样一个简单的贡献者信息——礼物发放——证书发放——英雄榜更新体系是一件十分耗时的工作：

须要一个个地去沟通、收集、复制、编辑、再复制...... 每有一个新的贡献者起码耗时20分钟，是十分折磨人的。

但这个经营工作落到了技术人员身上，流程就变成了：
  1. 和贡献者相互吹吹牛，而后甩过来一个表单
  2. 贡献者填完表单，飞书收到告诉
  3. 点两下鼠标，颁发一下证书
  4. 再点两下鼠标，用脚本更新一下官网

愈发感觉 DevStream 这个模式是胜利且高效、有肯定推广意义的，无论是技术人员辅助做些经营工作并进步整个团队的工作效率，还是经营人员本身去学些技术或者利用工具提高效率。

如果开源社区的运营者们不必每天身陷于重复性的无聊的工作，而是能有更多的工夫去做些创造性的工作、乏味的工作，那肯定十分酷！

链接汇合

  • 英雄榜
  • DevStream 新证书体系介绍
  • 开源社区贡献者与证书治理-模板
  • DevStream官网仓库
  • 数据格式转换仓库