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: 和合技~强释
- S06E05g56: 再次嗯哼
C-C 模式
- 即 github 的 Commit(提交)-Comment(点评)
- 是一种可以在版本页面逐行评注文本的功能
- 发现人追述: 「私塾7.1/36」和合技C-C模式
和合技 是参照圣经和合本翻译过程的一种小组互助写作技法
- 通过大家对同个稿件的多种方面/层次
- 进行反复多次的讨论和修订
- 获得超越所有成员本身写作能力之上的和合本

和合的内在要求¶

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

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

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

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->文件 来查阅全文
要是修订的行,引发了隔了几段的另外一行的问题
就无法简单的进行对应点评了

方案¶

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

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

分析¶

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

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

规约¶

过程中文稿的和合流程:

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

技巧¶

~ split视图

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

进一步的¶

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

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

和合技: BC 模式¶

~ C-C vs BC 模式

背景¶

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

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

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

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

所以, 小组联合写作时,自然的将代码仓库视作文稿仓库, 就能通过最现代化的协同平台, 来进行 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 对文稿进行整体和合修订
- 模式命名原创人追述: 「私塾7.2/36」和合技BC 模式

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

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

方案¶

~ C-C和BC 协同模式又有

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, 是我们对 和合技 具体行为的指代
- 参考:GC4g56: 和合技~强释

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

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

PS:

版本说明 在编辑页面的底部, Commit changes 那个表单
其实, 使用版本说明来包含丰富的信息,以及指令
一直是程序猿的习惯行为,在 git 时代更加丰富了
参考: Commit message 和 Change log 编写指南 - 阮一峰的网络日志

追加: 版本描述¶

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

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

v*版本(BC 和合技类型) 产生日期 作者

修订了什么
尝试了什么
大家应该作什么

比如:

 v5(BC) d4e2m 成果和合

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

以及:

 v6(BC) d5e2m 小俕怼

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

S07E15g193/ 嗯哼重来