「私塾7.2/36」和合技BC 模式

**小組:GS07E15gDAMA **
至此,我組摸索的Git-hub在和合技中的應用模式,已經初步完成。

特別鳴謝:
ZoomQuiet 他是知識的源頭,他引領小組,溯著他的已知,到達我們的未知。他完善正確,他修補缺損,他否決彎路。

安心竹 她穩重大氣,腳踏實地。她說,先空格,再遞交。她四兩撥千斤,為疑惑找到解決方案。

一坪海岸線 她善良溫潤,柔韌親和。她說,逐行空格,便可評論。她心思細致,將小組的聲音,在云端安放。

申小七 他揚鞭飛奔,磐石無轉移。他敦促節奏,靠譜真堅實。他說,還是要強調第一作者,于是[B-C模式]的出現得到有力的支撐。

和合技Github應用扼要

  1. 開放式咨詢,交流思路和意見--C-C模式
    C-C模式的說明,請參考 「私塾7.1/36」和合技C-C模式

  2. 顛覆性提案,強調整體效果--BC模式
    B-C模式的說明,正是本文的主要內容

  3. 應保證[BC模式]下的所有版本可進行開放性咨詢,符合C-C模式

  4. [BC模式]的觸發機制和版本說明,應根據不同和合題目的需求進行規約,在破題環節解決,因地制宜。

BC 模式規約

BC 模式定義

  1. BC 模式,即大裝修模式。
  2. 大裝修模式是使第一作者和其他修訂者獲得更直觀的整體修改效果體驗的和合模式。操作方法是,修訂者通過edit界面對原文進行整體修改,然后commit遞交。
  3. 簡寫:[Big Change Model]簡稱 [BC模式]

BC模式正文格式規約:

  1. 要求盡量每行都修改,或通過逐行空格,使得裝修后的新版,能夠以[C-C模式]開放咨詢。
  2. [C-C模式]在大裝修模式版本中的應用,可以使大裝修后的新版本能夠被逐行評論,同時統一所有歷史版本的格式,保持美觀。

BC模式 與 C-C模式的協同條件

  1. [C-C模式] 精髓是開放式咨詢,即意見交流,修訂者可以通過評論,描述其修改思路,方便修訂者與第一作者,以及修訂者之間的多邊交流。 *注:第一作者,[first-editor]-簡稱[fE]

  2. [BC模式] 精髓是顛覆性提案效果,即修訂者使用edit界面,按照自己的思路將原文修改后,呈現更為直觀的整體效果,并將之其提交為新的版本[commit],以供fE 參考,并請其他修訂者審閱及評論。

  3. [BC模式] 產生的新版本,應當采用[C-C模式] ,使得新版本對fE及所有修訂者開放咨詢,[BC]版全文可以逐行被評論。

  4. 只要有版本說明的細致規定,即[Commit Logging 規約],[C-C模式] 和[BC模式]可以協同混用。因此 [Commit Logging 規約] 是 [C-C模式] 和[BC模式] 的協同條件。

BC模式下Commit-Logging 規約 - 版本說明

扼要:fE_Vn_En_date

1. 引入“成稿” 概念--用 [Vn, n=1,2,3...] 表示

“稿”的概念其實在C-C模式中已經提到,當github應用在文字和合中,在gh預設的“版本commit”概念之上,應當有一個手動認證的“稿”的概念,高于版本。

引用[C-C模式] 說明
在github“版本”概念基礎之上,commit-comment和合模式提出整合多個“版本”的“成稿”的概念。即,通過時階性禁用edit功能,用更佳清晰的comment功能來記錄和合過程。避免github形成無效的新版本,將修改版本“隱藏”化,形成更層次分明的“成稿”迭代。類似photoshop中的合并圖層,跨越歷史記錄的時序,強調經過和合之后,文章當下的整體效果。如果沒有此成稿概念,很難再github中對版本進行分類分層

因為很容易出現就為了改一個字就出現了一個新版本,或者僅僅改了一個名稱就出現新版本的情況。多重無效版本堆積在commit history中不利于開放咨詢。

因此,我們賦予第一作者決定現在是第幾稿 (Vn, n=1,2,3...)的權利,手動體現在第一作者命名的版本說明中。

例如:

fE(小七)跑步文 - V3 第稿 - C-C模式開放咨詢

*注:其實最理想的名稱應當為 fE(名稱) -V3- C-C, 但因為該模式尚在摸索階段,我們鼓勵成員將漢語提示著明在版本說明中,以提高效率。

2. 引入[大裝修版本序號]概念--用 [En, n=0,1,2,3...] 表示

BC模式版本說明[Commit Logging]公式: fE-Vn-修訂者En-date

例如:

fE(小七)跑步文-V2第稿-小宋大裝修版 E1

這時,大媽想對小宋大裝修版進行再次大裝修,則大媽再次大裝修的版本名稱應為:

fE(小七)跑步文-V2第二稿-小宋E1-ZQ E2 - 20170311

然后竹子又來了,想對大媽再裝修版進行三裝修,于是版本名稱應該為:

fE(小七)跑步文-V2第二稿-ZQ E2-竹子E3 - 20170311

然后海岸線來了,想對竹子的三裝修版進行四裝修,于是版本名稱應該為:

fE(小七)跑步文-V2第二稿-竹子 E3-海岸線 E4-20170311

直到第一作者fE(小七)將版本名改成:

fE(小七)跑步文-V3第三稿-C-C模式開放咨詢-20170312

*注:
i. 只有fE可修改[Vn, n=1,2,3...] 的數值, 即成稿的序號,修訂者只能改 [En, n=0,1,2,3...] 的數值,即大裝修版本的序號。 在例子中,“成稿”的序列號“三”,是fE (第一作者) 小七決定的,所有修訂者不得修改。

ii. 理論上不需要著明[小宋大裝修版],因為修訂者的署名會自然顯示,而[En, n=0,1,2,3...] 本身就代表大裝修版[BC MODEL],但但因為該模式尚在摸索階段,我們鼓勵成員將漢語提示著明在版本說明中,以提高效率。

3. 其他說明

i. 如果在code入口,看到的是[BC模式]的版本說明[Commit Logging],則可以通過history回到fE發布的[C-C模式]。即:
code --> cimmits --> [BC模式]最新版本
code --> file --> history --> 當前文本的所有版本
通過兩個維度的轉換,實現[C-C模式]和[BC模式]的協同。

ii. 本著加速和合的原則,理論上應當規定,所有后來修訂者,應該針對同一成稿序號(Vn, n=1,2,3...)下的兩類文稿(C-C模式和所有En序列)均進行和合。

例如:

只要最新序號是第三稿,修訂者既要評論第一作者的開放咨詢,也須就其他修訂者的大裝修版進行評論,此外還可以自己完成一個裝修版。

但這三個和合的可能性均不做強制執行,有話想說才需要和合,沒話說,就保持沉默。愛用哪個或哪幾個方式,就用哪個或哪幾個方式,今日不想評論也ok。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容