IMHOGC4WP-番外GC4LW🐙复盟

S07E15g193: 嗯哼重来

2017-03-13  本文已影响139人  3908d6bf439d

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

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

TL;DR ...

知情咒批发组

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

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

计有:

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

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

和合技

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

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

和合技: C-C 模式说明

和合的内在要求

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

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

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

github 可利用的功能

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

Issue

非常象以往的 BBS:

所以, 不好进行 和合

Code

有道是:

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

没差别嗦…

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

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

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

直接修订

所以 不好进行 和合

C-C

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

C-C 使用中发现的问题

方案

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

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

分析

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

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

规约

过程中文稿的和合流程:

技巧

~ split视图

进一步的

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

和合技: BC 模式

~ C-C vs BC 模式

背景

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

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

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

TUV-orig.png

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

问题

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

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

通俗的说:

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

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

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

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

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

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

分析

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

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

方案

~ 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
+- ..

其中:

这样看起来好象:

问题在:

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
+- ..

其中:

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

PS:

追加: 版本描述

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

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

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

比如:

 v5(BC) d4e2m 成果和合

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

以及:

 v6(BC) d5e2m 小俕怼

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

猜你喜欢

热点阅读