[TUV]进行和合
Closed this issue · 13 comments
背景
全新的小组,全新的工具/界面/从业,,,
如何不崩溃?
分析
AKA~ All Know All 原则- 所有人知道所有 之时,以相同的节奏,共同怼文字
- 才能进入当年 和合本 小组的状态哪
参考:
- GC4g56: 和合技~强释
- GC4WPS03E05-番外 - 专题 - 简书
- 包含之前小组所有人两次作业的回顾小结
进展
- d1: 组队,配置环境,学习案例
- 1h 召人
- 2h 等待关键邮件,同时配置 github 仓库
- 1h 初始化有关仓库/issue/列表/示例文稿
- 1h 初始化wiki/zoom 会议体验
- 共计:4小时
- d2: 形成初稿
- 1.5h 手机github操作指南原型
- 2h Zoom 会议单口
- .5h 媒体整理/发布 修订群公告+引发任务
- 共计:4小时
- d3: 首次和合
- .5h 自怼文字
- 1h 嗯哼他稿
- 共计:1.5小时
- d4: 再次和合
- .5h 自怼文字
- 1h 嗯哼他稿
- 共计:1.5小时
- d5: 三次和合
- 1h 录音回顾
- 2h 微信怼流程理解
- 共计:3小时
- d6: 和合终稿
- .5h 自怼文字
- 1h 嗯哼他稿
- 共计:1.5小时
- d7: 回顾和合 ~ [TUV] 理解和合
- d8: 和合定稿:
- 2h zoomq 会议
- 1.5h 整理总结
- 共计:3.5小时
- 总计: ~ 16+小时
@GC4WP/zq4s07e15
暂定每天
20:30~21:30 和合会议
会议入口,提前5分钟发布
首次议题:
- 作业要求的坑有什么, 如何破
- 小组协同的流程是如何的, 怎样最大化和合次数
- 体验语音和合...
昨夜视频一早爬了一半，爬爬停停中演练，关于提到和合的三个想法：
1、五人五篇和合，是否需要制定一个大致的共同目标主题，再去发挥，最终的和合效果会更好呢？
2、关于新鲜一词，赞同大妈的定义，互联网无新鲜，那么小宋的关于自我的新鲜体验应该可以是个好的提议；
3、关于大妈提到的不用文字标点符号，会加强文字的文气，仔细思量很有意义。当没有标点的时候确实需要用更多的文字思量去写好好中文本身，但我也在思考是否最终写完了后，再加标点符号会更好呢？没有完全想明白。
昨夜不是在酒店没有办法接入进来，而是应酬喝大酒，今天一早全部看了一遍，收获很大很多
S07E15G193和合术第一次会议纪要
主题：被大妈踹开的新世界大门与共建共享GITHUB
时间：2017/03/07 20:30-21:45
主持人：ZOOM.QUIET
参会：海岸线、安心竹、宋偲瑄
议程一：介绍什么是dashboard/issues/commit
文字的琢磨是无穷无尽的，琢磨的过程既充满魅力也需要投入大量精力。
如果有一个好用的工具，能够给不在一处的人、又不方便同时进行讨论的创作群体提供可实现的琢磨与修改，
无疑，文字的琢磨工作就会徒生各种乐趣，也提升效率。
能帮我们放大这种乐趣和实现各种和合功能的工具，就是GITHUB WEB版本。
作为非程序猿的我们，只要善用GITHUB的三种功能就可以了：
-
dashboard
导航而已。其实就是一个导航页，告诉使用者你在多少资源仓库里，你会根据不同的目的，进入各种仓库。 -
issues
问题合集。这更像是大家在使用工具当中、理解选题、和合方法、流程协作或遇到各种围绕文字创作可能遇到问题的题板。有人放出，有人解答，最后形成一个指导大家解决问题的决定性答案。 -
commit
进行版本评注的地方。在这里，所有人可以点击commit项，就可以看到所有人文章的所有版本。随时随地进入任意版本，就可以对原作的每一版，每一行，进行评注。评注只是提意见，但如果愿意直接修改，可以点击“code”项下的对应学号文章文档，就可以完成。不必担心效果，因为所有版本都会留存，操作其实都算是可逆的。 -
code
成品或作品存放地。issues是讨论问题的合集，而 code则是我们文章的存放地。本次大妈提前为大家建立好了对应文档，在此特别感激。
议程二:破题
破题的过程就是认真思索本次作业的真正目的，避免做成无用功。本次作业即将形成的5篇文章，最终会以一个合辑的形式提交。如何做到独立又完整，一路引人入胜，文字优美（其实就是听起来悦耳）其实是一个很大的挑战。很像是编辑一本年度精选集的感觉，需要让读者迅速地、酣畅淋漓地通读下来。
而对选题中“4+2”的理解，基本又是在大妈的“单口论述中”完成。而对新鲜一词，宋偲瑄则提出她的理解。她认为新鲜是对于她写作角度或认知中的新鲜，也就是相对作者而言。大妈的理解则是对自己普通或熟悉，但却让读者感到新鲜和好奇。
此处对新鲜的理解，本次会议赞同两种理解。
议程三：和合的流程
- 在ZOOM会议上，作者向大家读自己的文章，大家通过这个过程，找出文章的问题，进行和合。大家可以在作者读的过程中，打开GITHUB对照着文章，直接修改或点评。
- 每天自己至少完整修改一次自己的500字文章。接受大家的点评、修改。可以根据大家的点评自行判断，是否需要采纳意见。
议程四：ZOOM和合大法实测
大妈首先演示了通读《焖土豆儿》的过程。并邀请大家开始进行和合互怼。
- 安心竹的意见：最后一段需要主语
- 宋偲瑄的意见：最后一段的感慨过于露骨
- 海岸线的意见：虽然大妈强调没有标点，文字的力量会强大，但个人认为如此画面感的叙事，不加标点后，让文字过于硬朗。
任务与总结
和合一次会议媒体资料:
http://sina.lt/eTsn
引发额外任务:
@193-天津-海岸线 义务记要在
#2
@029－HK－宋偲瑄 研究发布 dashboard 进入说明
@026-上海-安心竹 总结发布 github 全手机使用手册
收集回复在:
#1
速度翔实的会议记录
S07E15G193和合术第二次会议纪要
# 主题：在GITHUB世界和合 S07E15g193作业通读一
时间：2017/03/08 20:10-21:20
主持人：宋偲瑄
参会：海岸线、安心竹、申小七
议程一： S07E15g193作业方向讨论
继续深入讨论对于本次《和合本与白话文》S07E15作业的理解，并就Zoom.Quiet多次提及的画面感、新鲜等等的G4+2进行回顾和讨论思考，同时对于作业的选题方向讨论，不管主题，大家各自写想写的，然后共同去和合去讨论去完成。
议程二:通读朗诵S07E15g193组员作业
一、《那个味道》海岸线文 申小七朗读
宋偲瑄提问：苍蝇和蛆代替棉被的转换过快，时令的转换，需要描述主人公的第二次的不适感；
海岸线回复：时间的跨度，从夏季，半年的跨度到冬季，最终因为使命感和工作意义恐惧感的消逝；
申小七感受：朗读的过程中，感受到语言文字的美，和画面的生动，但有不够平易、浅显的感受；
海岸线回复：小七的儿化音无法朗读，对于平易需要琢磨，疏通；
申小七提问：前后两篇文字暴力悬念的起因；
海岸线回复：第一稿是大妈的提议抛出始稿，但大妈的回复说这只是复述人生的一种自我体验，触发重构的想法，通过当天本地电视的新闻纪实故事，写出第二版故事稿件；
大致总结：文字的触动人心与输出，如何有效的去构造和思考描述需要继续进行。
二、《焖土豆》Zoom.Quiet文 宋偲瑄朗读
申小七感受：大妈最后的一段非常好，和昨天晚上会议大家说描写的太明了感受不一致；
海岸线回复：具体焖土豆还是需要细化，其他都非常好；
宋偲瑄感受：整体文字给人感觉非常豪放；
安心竹感受：以一个孩子的角度去描写，用词方面有大人的语言刻画，回到孩子的语言结构；
整体感受从文气方面此文还是禁得起大家推敲和阅读的，文字的画面感，美感都很强，因为没有标注标点符号，将文字的打磨更有效；
三、《疯人院的中秋节》安心竹文 海岸线朗读
申小七感受：短短五百字，但人物出场太多了，给人感觉太凌乱，画面感太强；
宋偲瑄回复：描写疯人院中秋节的画面横截面，类似清明上河图，文气突出；
安心竹回复：中秋节的温暖氛围下去刻画一个凄凉；
宋偲瑄回复：疯人院的人们沉浸在自我世界里，也了解文章中有描述横截面的方法；
海岸线回复：朗读感受很平易很顺畅的感受，宋偲瑄的解释很赞，这个横截面概念引出很吸引人；
申小七感受：人物的画面感虽然很强，但如何去抓住重点，交错感太强；
宋偲瑄回复：有没有看《红楼梦》《三国演义》一开场很多人，继续往下看即可，抓住每个人的画面和特点特征；
申小七感受：五百字去堆积这么多人还是有保留意见；
最终结果就是一个傻男人不懂女人心
任务与总结
@193-天津-海岸线 义务记要己发布
#2
这次申小七义务书记 请~
又其它引发继续等待ing:
@029－HK－宋偲瑄 研究发布 dashboard 进入说明
@026-上海-安心竹 总结发布 github 全手机使用手册
收集回复在:
#1
PS:
修订群妮称 结构为
学号-城市-姓名/网名
比如俺:
57-珠海-Zoom.Quiet
S07E15G193和合术第三次会议纪要
时间：2017.10.09.20:30-21:30
主持人：zoom.quiet
参与：申小七，海岸线，安心竹
主题：作业朗读与點評
议题一.关于和合技之修改意见
github点评模式中，小加号只会出现在对于上个版本修改或过的那一行。如果想修改别的行，可以打开其他历史版本。
议题二作业朗读与点评
1.宋偲瑄的文章，大妈朗读
安心竹：有真情实感，语句方面需要再改改。
海岸线：语句还不够口语化，第一段场景不明白外婆如何认出外公，喜欢最后一段的描写。
申小七：关于文字运用，如何看文采与平易的关系？
大妈回答：举例圣经翻译，实践证明平易文字更适合大众，写文章不是为了自嗨，而是为了给别人看。要将自己想表达的让别人get到，就不能一味只顾文采。又比如编程，刚学习时，觉得复杂的技能很好，后来发现，越简单，项目越好推进。又比如围棋，背复杂的定式，也不如回到最原始的方法，一步一步下。
大妈点评：文章的内核或者主题句没有。
2.大妈的文章，本人朗读
安心竹：听出来改了很多，本来写得像工程，现在听上去更像是小朋友一起玩。有一个问题，究竟fresh指的是什么？
大妈回答：没有特别的定义，你自己觉得fresh，并且让读者感觉到。精准，流畅，那必须自己很了解，但别人觉得新鲜。
海岸线点评：行文更流畅，语言更平易。
申小七：结尾一段去掉有点可惜。为何不能写宏大场面？
大妈回答：宏大场面可能需要更多技巧，目前来说，500字以内，可能小场面更合适。说不清的东西最好就不说。
申小七：明白了叙事角度切入点。
大妈：关于儿童文学，目前国内儿童文学都是翻译腔，实际上小朋友有能力接受理性思维。
海岸线点评：感觉文末“苍凉”一词有些突兀。
3.安心竹文章，本人朗读
大妈：读的时候你改了很多，因为语感不对。文末那句月亮的感慨，在文中人物身上未表现出来。你去过疯人院，别人没去过，你需要让别人get到你感触最深的那一刻。还是选取合适的场景，或者选择更能驾驭的题材？
海岸线：细节方面改了很多，更有画面感，用对话的方式将故事串起来。但那种凄凉的语境和疏离感却弱了很多。
申小七：还是觉得人物太多，一时不能抓住重点。
4.海岸线的文章，本人朗读
大妈：选材立意都很好。建议多多了解法医行业，看网页至少100个链接，看相关方面书籍，最好找个法医聊一聊，才能写得更符合实际也更精准有力。
申小七：同意大妈观点。
安心竹：同上。
大妈：此次小组和合体验如何
其余三人：和合速度快，要求严格，进步快。
任务与总结
和合d3记录:
http://sina.lt/eTxk
思考分析:
试说 github 如何加速了文稿的和合速度? 识别出哪些是和合行为了,就发现了自己的和合技!
回复收集在: #3 issue
那天引发任务还少小宋:
研究 dashboard 进入姿势
在: #1 Issue
目前和合流程:
- 随时通过 github 对所有文稿进行和合/点评
- 每天至少和合自己文稿一个版本
- 每天定时一小时 Zoom 和合会议
(20:30~21:30)
#成员笔记－宋
任务列表:
- 解决会议录音云储存技术
- 解决引用语法
[时而好用时而不好用，查找小七历史版本中不好用的原因]
- 逐字修改小组每篇文章
［3月10日晚上Get］ - 试完成合集第一版
- 会议交流合集思路
- 解决在project中导入code topic技术
- 速记符号-+ 是替换 ++是补充
［基本Get］ - 大妈如何导出微信群记录
［邮件导出群记录功能Get］ - 完成commit-comment模式纪要说明
［3月11日下午15点get］ - 大妈怎么画这个图：
@BrookSongBrookSong 嗯哼? 原先的故事更加好哪,怎么 cut 到没尾了!?
man -> iland
^ -> girl
| +- fishman ---------+
| +----< +- baby |
| | -> as new fishman |
| +-------> grow girl |
| |
+-----new loop------------------+
变样就变成了时空封闭的 sifi 故事了...
- 理解commit-logging ［GET］
12.活跃图谱
Punch card · GC4WP/S07E15gDAMA
https://github.com/GC4WP/S07E15gDAMA/graphs/punch-card
可以清晰的看到大家的嗯哼时间点
13.blame平滑挖掘页面追踪 - RAW 源代码
- fork用法
任务与总结
和合d5音频记录:
http://t.cn/RiERpGZ
S07E15G193和合术第四次会议纪要
时间：2017.10.09.20:30-21:30
参与：申小七，海岸线，安心竹，宋偲瑄
议题一.关于和合技之修改意见
大妈提出的大装修模式可以带来全新的和合体验。
但这引发了三个和合需求的异端：
- 程序猿的协同工作，只要确保程序可运转，无第一作者概念。
- 圣经的和合模式，都是上帝的代言人，没有第一作者。
- 本次小组合作，怼出五篇有第一作者的文章。
针对本次作业，共识：
大装修模式可以带来全新的和合体验，但是应当在与c-c模式的搭配使用中，应当由第一作者在issue中发布阶段规约。如，现在029-第一稿 进入大装修模式，截止日期3月15日晚上8:00pm。现在029-第二稿进入commit-comment模式，截止日期3月16日晚上8:00pm。第一作者需要发布这样的命令。小宋认为，这样的做法可能会一定程度上限制灵感发挥，但作为一种合作模式，就是需要一定的规约，来提高合作的效率。海岸线认为，如果在c-c模式下有人想进行大装修，可以保存在本地／存在issue中／另起一个文档，以免打扰c-c进程。
书记补充：此外，在所有文档之外，应当另起一个文档叫做大装修。如果在第一作者发布的c-c模式命令下，有修订者想要进行大装修，可以将其纪录在大装修文档中作为一个版本，然后在大装修模式开启后，再复制粘贴到原文档中。
会后思考
c-c模式和大装修满足了不同的需求，比如小宋，面对一篇文章，有时候没有大装修的欲望。所以很是赞同c-c模式和大装修模式阶段性交替进行的方案。这样大装修不会打断c-c模式中对于多人修订意见的和合。而大装修期间，不限制成员针对任意装修版本的comment。每一条改动，都被认为是一次和合，那么一次大装修，就统一发布了多次和合，这多次和合又会在split对比视图中体现。**所以大装修的确会加快和合速度。**但c-c模式不可替代的，是多名修订者之间针对同一版本，跨越时序的交流。
因此会议的共识是，c-c模式和大装修模式都非常有价值，但不可在同一时段混合使用。
会后再思考20170313早上（会后清晨）
- blame界面可以做到split对比历史版本
- 只要有文件名称的规约，c-c模式和大装修模式可以混用。c-c模式的精髓是意见交流／修改思路交流，而大装修模式是更为直观的修改效果交流，当然大装修后也可以在整体comment里说明大装修的思路（大装修格式规约：要求尽量每行都修改，或通过空格使得装修后的新版可以c-c模式开放咨询，统一格式避免麻烦）。c-c模式和大装修模式可结合，只要在版本名称上有细致的规约，使人一目了然。
版本名称规约
例如：
小七跑步文－第二稿－c-c模式意见征询－20170311。
小七跑步文－第二稿－小宋大装修版－20170311
如果小宋大装修了两版，则还有
小七跑步文－第二稿－小 宋大装修版2-20170311
这样如果在code入口，看到大装修版的版本名称，可以通过history回到上一个意见征询版本，进行c-c模式点评。
如果在这个过程中，作者突然想要整体大修一番，修正之后开放咨询，则需要把版本名称改成：
小七跑步文－第三稿－c-c模式开放咨询－20170311—02
议题二作业朗读与点评
安心竹的文章（大妈大装修版）：
朗读者－小宋
小宋认为：perfect，特别顺口，无卡壳。
安心竹：大妈很多修改很细致，去掉量词很好。
小七：大妈修改很赞。
海岸线：大妈是画面运用的高手。
小七的文章（历史版本，小七亲自改的最后一版）：
朗读者－小宋
小宋认为：perfect，特别顺口，无卡壳。
小七问题：小七觉得大妈的简洁用语很赞，小宋怎么看待这件事？
海岸线：有一个朋友，画画好得无法模仿。朋友说，其实画面原本就存在于你自己的脑海，只要经过专业的画画训练，就能让手脑合一，把脑子里的画面呈现出来。
小宋答：写作者内心先有一个图景，然后才把图景写出来。把心中的图景落到纸上的过程，叫做写作技巧。但是在写的过程中一定会有对心中图景的细节性遗忘或忽略。和合就是别人说说别人从你的文章中看到了什么，或者应该怎么改。如果这个改的符合你心中原有的图景，或者弥补了你在描写图景时遗漏的细节，你就觉得对对对。如果和合不符合你当初的设想，就需要反思你在写作过程中怎样让别人产生了这样的误解，怎样调整。小七觉得大妈说的好，一定因为大妈的用语符合小七的预期。
海岸线（海岸线的最后一版和大妈的大装修版都有读）
朗读者－小七
小七认为：海岸线版比较顺当
海岸线：大妈是画面描写的高手，非常多修改很合理，值得借鉴。
会议录音, 小七发布：链接: https://pan.baidu.com/s/1eSBV03K 密码: qai5
S07E17g193: 嗯哼重来
佩哥哥一声令下, 原先好容易磨合成功的小组,
不得不破出门户,另行嗯哼...
原本以为只是普通的 重复基建 没想到
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 模式
- 即 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的第一个大装修版本
- E0 即初稿, 本质上也是
这样看起来好象:
- 将
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的第一个大装修版本
- E0 即初稿, 本质上也是
+:后面是提交时版本说明的前缀示例e2m~ Easy to Merge, 是我们对和合技具体行为的指代
嘦约定好提交时的版本说明, 就可以令:
Code->Commits列表 以及Code->file->History列表中- 都能清晰的看到:
- 所有修订都是什么状态中的
V*(e2m)都是fE发布的大和合版V*(BC)都是成员大装修的非集体和合版
- 进入任何一个版本,都可以 点评
- 同时,
fE也能在一个界面中知道有多少BC版本,以及BC和自己和合版本的差异- 事实上, 这种自动的差异标定, 也就等于成员的批量点评而已
PS:
版本说明在编辑页面的底部,Commit changes那个表单- 其实, 使用版本说明来包含丰富的信息,以及指令
- 一直是程序猿的习惯行为,在 git 时代更加丰富了
- 参考: Commit message 和 Change log 编写指南 - 阮一峰的网络日志
DONE as good! 达成/归档/交付ed