S07E15g193: 嗯哼重来

佩哥哥一声令下, 原先好容易磨合成功的小组, 不得不破出门户,另行嗯哼…

原本以为只是普通的 重复基建 没想到

TL;DR …

知情咒批发组

才4天就已形成内部的很多新咒:

  • 和合仪式
  • 通读怂怼
  • C-C模式
  • 大装修模式
  • 第一作者

可能因为组里女生多, 对各种细节敏感, 发觉有一丝不嗯哼, 就立即挖掘, 直至明白并折叠为新咒, 以及面向半年前的自己, 整理为小教程…

计有:

  • github 注册说明
  • 全手机 github 使用手册
  • 如何 github-issue 图片发布
  • commit-comment和合模式解决的核心需求
  • 大装修模式[B-C MODEL]规约

简直将 github 各种表面功能挖了个底儿掉..

也生生前后挤出俺这8天 16 个小时的精力投入到越来越有趣也越深入的 怂怼和合中来…

和合技

这次对具体的 和合技 积累的不多, 只复用了之前小组约定的几点, 创新的 和合技 是利用 github-project:

  • 类似 Kanban 系统的界面
  • 快速直觉性的, 每人排出一个专辑次序
  • 立即在 zoom 会议中逐一讲述基于的原则
  • 公投定序

过程流畅的象用了很多年的老司机, 不觉进一步的赞叹, github 功能设计的太傻瓜化了, 太好用了

和合技: C-C 模式说明

  • 参考: GC4g56: 和合技~强释
  • C-C 模式
  • 和合技 是参照圣经和合本翻译过程的一种小组互助写作技法
    • 通过大家对同个稿件的多种方面/层次
    • 进行反复多次的讨论和修订
    • 获得超越所有成员本身写作能力之上的和合本

和合的内在要求

一般网络团队,成员分布在全球各地无法象当年的和合翻译小组, 可以当面拿着同一份文稿逐字讨论

但是,通过网络却是可以基本达到相似状态的, 只要解决以下主要问题:

  1. 看到完整/通畅的全文
  2. 看到具体修改了什么
  3. 可以快速对不满意的那一行进行点评
  4. 其它人可以同时看到其它所有人的点评
  5. 作者可以在任何时间随时自主将所有点评意见权衡后决定如何修订
  6. 作者可以随时发布修订好的新版本文稿

github 可利用的功能

在 github 中可以进行大规模文本编辑的功能有三处 不过,一般使用其中两个:

  • Code ~ 代码仓库
  • Issue ~ 提案池

Issue

非常象以往的 BBS:

  • 提案建立后,大家就可以回复发表意见
  • 想进行和合的话:
    • 大家的修订将在越来越长的回复列表中
    • 作者想找到具体某一句的修订意见将越来越困难

所以, 不好进行 和合

Code

有道是:

代码是给电脑读的文章
电脑理解其义相应动作
文章是给肉脑读的文字
肉脑理解其意相应感动

没差别嗦…

所以, 虽然 github 的所有功能都是针对程序猿进行代码管理的, 也照样可以在和合写作中用起来 ;-)

只是, 具体操作时,得有点技巧,这点是 (@029-HK-宋偲瑄 敏锐的发现并宣告出来的)

将原先的代码仓库视作文稿仓库后:

  • 每次修订自己的文稿,提交
  • 其它成员,立即可以从 Code->文件 路径中查阅到最新版本的全文
    • 解决前述 1/4/6 三个需求
  • 但是难以立即点评感觉有问题的那一行
直接修订
  • 如果直接用编辑进行修订话
  • 一提交,将在正文中留下修订意见
  • 导致再刷新时正文原有的流畅阅读体验被中断
  • 以及其它3个问题

所以 不好进行 和合

C-C
  • 从 Code->文件->History 路径
  • 进入文稿的修订版本列表, 点击任一版本
  • 进入 Commit 页面,记录了修订,以及和前一版本的差异处
  • 又支持点击任一行头部的 Comment 符号来进行点评
  • 作者可以随时经由相同的访问路径看到大家各自的点评
  • 甚至于可以回复相关点评,直接展开文字讨论
  • 综上解决了前述 和合 需求中:
    • 2/3/4 问题问题

看起来完美解决所有 和合 协同的需求哪

C-C 使用中发现的问题

  • 如果作者某次只修订了一行文稿
  • 则在 C-C 界面中,只能看到前后3行文稿
  • 问题1 没有同时解决
  • 我们不得不另外开一个窗口,从 Code->文件 来查阅全文
  • 要是修订的行,引发了隔了几段的另外一行的问题
  • 就无法简单的进行对应点评了

方案

仔细一想其实就这么几个解决方案

  1. 每次修订后,都提交一个新文件,这样所有行都能点评
  2. 每次修订, 都修改每一行,这样自然所有行都能点评
  3. 每次修订, 对没有修改的那些行, 进行一些不影响阅读的修订,以便所有行都能点评
  4. 等待 github 开发相关功能,可以令 C-C 界面中看到所有没被修订的行

分析

前述几种应对稍一思量就知道:

  1. 这样将无法知道和前一个版本相比修订了什么
  2. 这是最好的方式, 也是最累的
  3. 这个可以有,但是,用什么方式可以快速追加什么看不到的修订?
  4. 这是种不现实的期待

规约

过程中文稿的和合流程:

  • 作者尽力修订每一行, 如果不能,提交前在所有行前追加空格(下次提交可以再删除能些空格)
  • 所有其它成员通过 Code->文件->History 点击最后的一个版本(Commit)
  • 根据自己的理解/通读感觉, 对有问题的那一行使用 点评(Comemmt) 功能留下意见
  • 作者在进行又一次修订前, 要通读所有点评,自主决定怎么和合
  • 继续以上操作序列的循环处置

技巧

~ split视图

  • commit界面有两种视图
  • unitied 视图
    • 是将前后两个版本的文本间杂的显示,这样很影响完整的通读感觉
  • split 视图
    • 则是将前后版本文字,以左右分离的形式来显示
    • 即可以对比各行的变化
    • 有有流畅的阅读体验
    • 也能随地点评
    • 唯一问题就是对显示屏幕有要求,对手机过小的屏幕就很难受了
    • 所以, 推荐使用桌面电脑大屏幕在此视图中进行和合点评
进一步的

综上, 可以快速的对所有行的前/后 追加空格可以解决所有问题

  • 那么, 什么方式可以作到这点呢?
  • 简单的说: 用个对的编辑器
  • 大妈推荐: Sublime Text 3

和合技: BC 模式

~ C-C vs BC 模式

背景

作为一头程序猿, 每天都在使用 github(常见缩写为 gh), 一般对 gh 中的代码有两种处置:

  1. 先同步团队成员昨天修订的代码, 然后进行理解/测试/修订/提交
  2. 根据邮件或是 gh 界面上的提醒, 查阅爱好者推送来的 Pull-Request (合并请求), 决定接受哪个合并,并将合并后的代码提交

而竟然和100多年前的圣经 和合本 诞生过程非常相似:

  • TUV ~ The Union Version 和合本创作技巧 (TÜV 也是德国技术监督协会及认证的简称,以示这是一门严格的技术)
  • 是 1891 年度开创性翻译圣经的方法,包含中国文人和外国教士组成的小组,
  • 使用 7柱式和合帐本 来记录译文的版本变化:
    • 从左向右7列
    • 分别是 初译->1审..4审->和合->定稿
    • 译文竖写, 这样如同现代敏捷软件团队使用的 Kanban 一般
    • 译文的每个字,都通过多轮次 review 最终和合出最合适的

TUV-orig.png

所以, 小组联合写作时,自然的将代码仓库视作文稿仓库, 就能通过最现代化的协同平台, 来进行 TUV 了.

问题

第一时间规约好的 和合 流程:

1. 随时通过 github 对所有文稿进行和合/点评
2. 每天至少和合自己文稿一个版本
3. 每天定时一小时 Zoom 和合会议

通俗的说:

每天每个人对自己的文稿就是那个主审
    每个人对其它人的文稿就是四评
每天至少和合一次
    就是自己应该定期将其它人的所有点评意见
    自行和合出一个新版本来

并很快发现 gh 点评功能的特性,并进行了进一步的增强,即 C-C 模式

参考: 和合技C-C模式 确保每次提交文件时, 文稿的每一行都有修订,或不可见的空格变化 这样可以高效利用 Code->file->History->Commit 中的 comment 功能 进行随时的和合讨论,节约会议时间

但现实总是超出意料, 当前这一流程中:

  • 如果会议因为有些原因没有进行, 对文稿的点评/意见没进行讨论怎么办?
  • 如果 第一作者 每天因为有原因没有完成和合,其它人可以主动进行嘛?
  • 如果点评难以对一个跨度远的 两/多处 进行完整的修订说明, 怎么办?

于是自然的, 俺对其它成员的文稿进行了逐一行修订,并提交, 跳过了先点评, 等 第一作者 的和合.

立即,引发了成员们的思考, 这样好不好?

分析

~ 当前和合文稿的流程中各种概念和角色

  • 仓库 -> Code -> file (各种 .md 结尾的文件) 即文稿
  • 第一作者 -> fE ~ first Editor 对应文稿第一个版本的提交人, 即原作
  • C-C 模式 -> Commit-Comments ~ 提交-点评 模式, 通过 gh 提供的 版本(commit) 页面中的点评(comment) 功能, 方便的将原文/和合意见/讨论 统一在一个界面中,以便 fE 可以有的放矢高效完成新的一个版本
  • BC 模式 ~ BigChang(大装修)模式 即直接替代 fE 对文稿进行整体和合修订

在进行了高速的思考和交流后,嗯哼了共识:

  • fE 对文稿天然更加理解, 因为这是 TA 内心的创造性成果,根据其它成员给出和合点评来和合是好的
  • 和合中的贡献是复合的:
    • C-C 中的点评
    • 正文中的修订
    • 通读的献声
    • 会议中的讨论
    • 流程/技巧的思考分享/演练
  • 和合技 要着在快速反复的进行讨论和修订
  • C-C 后等待 fE 来和合, 以及直接进行 BC 修订, 都是允许的
  • AKA ~ AllKnowAll 原则也是 和合技 的精神内容:
    • 即确保: 全体对所有修订以及修订意见都应能简易可见
    • 仓库中最新版本的文稿是否由 fE 完成并不重要

方案

~ C-CBC 协同模式又有

C-C + BC

Code ................ | ... History->Commit ....
|                          |    |   |     |
|                          V    V   V     V
+- s07e17_010.md        << Vn .. <- V1 <- E0
+- s07e17_010_V2-011.md
+- s07e17_010_V2-100.md
+- ...
+- s07e17_011.md        << Vn .. <- V1 <- E0
+- s07e17_011_V1-010.md
+- s07e17_011_V3-100.md
+- ...
+- s07e17_100.md        << Vn .. <- V1 <- E0
+- ..

其中:

  • V* 代表某 C-C 版本,为 fE 和合相关意见后的版本
  • E* 代表某个 BC 版本,即大装修版本
    • E0 即初稿, 本质上也是 fE 的第一个大装修版本

这样看起来好象:

  • fE 的所有版本,收集在固定的文件中并配以对应的点评
  • 又同时通过 BC 的新文件, 配合文件名约定,以便:
    • 知道是从哪个版本中 大装修 出来的
    • 以及是谁进行的 大装修

问题在:

  • 仓库目录中的文件将高速增长
  • 同时, fE 想知道 BC 和自己有关版本的差异也只能用肉眼
  • 进一步的, 对 BC 版本的点评也分散在越来越多的文件版本历史中

C-C | BC

~ 相信 gh 的能力, 约定人的行为就可以更加 easy

Code ........... | ......... History->Commit ..................
|                     |    |   |     |
|                     V    V   V     V
+- s07e17_010.md  << Vn .. V2 <- V1E2 <- V1E1 <- V1 <- E0
|                           |      |       |      |    +: inti. 
|                           |      |       |      +: V1(e2m) ...
|                           |      |       +: V1(BC) ...
|                           |      +: V1(BC) ...
|                           +: V2(e2m) ...
+- s07e17_011.md  << Vn .. V3 <- V1E1 <- V2 <- V1 <- E0
|                           |      |       |    |    +: inti. ..
|                           |      |       |    +: V1(e2m) ...
|                           |      |       +: V2(e2m) ...
|                           |      +: V1(BC) ...
|                           +: V3(e2m) ...
+- s07e17_100.md  << Vn .. V2 <- V1E1 <- V1 <- E1 <- E0
+- ..

其中:

  • V* 代表某 C-C 版本,为 fE 和合相关意见后的版本
  • E* 代表某个 BC 版本,即大装修版本
    • E0 即初稿, 本质上也是 fE 的第一个大装修版本
  • +: 后面是提交时版本说明的前缀示例
  • e2m ~ Easy to Merge, 是我们对 和合技 具体行为的指代

嘦约定好提交时的版本说明, 就可以令:

  • Code->Commits 列表 以及 Code->file->History 列表中
  • 都能清晰的看到:
    • 所有修订都是什么状态中的
    • V*(e2m) 都是 fE 发布的大和合版
    • V*(BC) 都是成员 大装修 的非集体和合版
  • 进入任何一个版本,都可以 点评
  • 同时, fE 也能在一个界面中知道有多少 BC 版本,以及 BC 和自己和合版本的差异
    • 事实上, 这种自动的差异标定, 也就等于成员的批量点评而已

PS:

追加: 版本描述

参考:Commit message 和 Change log 编写指南 - 阮一峰的网络日志

对于我们嘦最小模板 标题是对版本的压缩描述

v*版本(BC 和合技类型) 产生日期 作者
  • 修订了什么
  • 尝试了什么
  • 大家应该作什么

比如:

 v5(BC) d4e2m 成果和合

- 删除4,5 两节
- 增补会议意见
- 今天怼的入口

以及:

 v6(BC) d5e2m 小俕怼

- 根据一周理解
- 嵌入大妈语言结构
- 尽量完善逻辑链条

Comments



蟒营®编程思维提高班 Python版/第14期 正在报名

精品小班/ 永久答疑

扫描报名: 101camp14py

蟒营®式 原创课程

theory101camp_v3

官网: py.101.camp


任何问题可先进入知识星球(免费)咨询:
FAQ

关注公众号, 持续获得相关各种嗯哼:
zoomquiet

追问

任何问题, 随时邮件提问可也:
askdama@googlegroups.com


© Copyright 2014 by Zoom.Quiet
Content licensed under the Creative Commons attribution-noncommercial-sharealike License.
Contact me via , mail ,github or gitlab . Tip me via Buy me a coffeeBuy me a coffee || (feed)