20141109 自發參與者誤觸非鬆散開放任務之自我檢討與防呆機制設想
事件日期：2014/11/09 g0v summit unconference
敘述視角：Bropheus Huang 第一人稱
venev文長慎入：本 pad 內含「事件後的道歉、自我檢討、重建現場、釐清細節、未來可執行之行動界線、（負面情緒下）溝通方式探索與修正」等多重主題，經旁觀者提醒內容太滿，道歉宜控制字數、避免加入過多資訊。以下需要爬梳整理，請以史料、素材看待。
2014/11/12 22:52 小結
先強調一下，我現在認為最主要的問題，在於我把 2014/11/08~09 這兩天的活動籌辦與支援，當作是開放參與、彈性協作的項目，所以在很多行事細節上使用了錯誤的預設，造成很多不必要的困擾，這點我感到非常抱歉。
我不認為完全是因為是否為開放參與造成的問題，同下述範例「就算萌典松是開放參與，我不會帶燒烤爐去 bookshow 烤肉給大家吃，然後 ask for forgiveness.」，這是基本 etiquette
我完全不認為是「並非開放參與」的問題，我認為是「我誤以為是開放參與」的問題，關於烤爐與「轉接頭」執行細節的事情，剛好是我正要討論的一件事，也請 clkao 稍待一會多予指教。
但另一方面，我認為這個事件反映出很多「不管是開放協作或指揮統籌，組織運作會面對的困難、魔鬼細節、可能的防呆機制設計」，如果簡單的以道歉結束、停止研究就太可惜了，所以我會繼續敘述相關的事情，先寫到這裡。
簡單來說，就是「尊重」二字，無涉其他。summit 籌備半年，招募工作人員時間相當長，防呆機制也相對完善很多。除了道歉可能也要思考基礎的行事準則。
防呆機制很簡單，事前多問多打聽就好了，不管拍片還是辦活動還是做什麼事情，這道理其實都一樣的 XD
2014/11/13 04:05 小結
這則小結的標題，原本應該是 2014/11/13 03:46。
但從打下標題，到打下第一行之前的這十九分鐘，心裡實在是感慨萬千，不得不再次停下來，整理一下情緒。
當時我在這個已經很長的 pad 中，還有另一個地方，看到一些話。據我的不專業解讀，我相信原敘述者的意思是：我[寫在此處的文字裡]缺乏溝通和道歉的誠意，並且硬凹。
au 補充好快 XD
我相信原敘述者一定有這麼解讀、這麼認為的原因，所以我也很用力往前文去找、去回想，可能在什麼地方造成了這種印象，或者我沒有成功表達出我心中的誠意。但我沒有很明確找出來是哪些地方表達得不好，所以又轉個方向自我懷疑了一下：是不是我真的沒什麼誠意，所以當然沒表達出來；或以（我不太瞭解的）對方的標準來說，我自己感受到的這點誠意其實遠遠不夠。但這兩項在理論上都不是我（至少是現在）能夠準確衡量的標準，所以試了一會兒之後就打住了。
再次補充：我覺得你在此處的文字很有誠意重建現場、道歉、修正溝通程序、理清不確定的細節。
只是呈現的順序次第往往相反了...
趕快趁機問一下，au 你覺得是一開始貼的全文有順序次第的問題，還是在 // 對話裡面也如此？
主要是一開始的架構，對話是順著架構展開的。
變成了「理清不確定的細節」->「修正溝通程序」->「道歉」-> (可能沒有完全)「重建現場」...
其實這也並非無理（所謂 bottom-up 思考），只是或許與受影響者的期待有異。
嗯... 其實一開始的全文架構，也不是完全按順序寫成，是我寫了很長之後，決定調動整理一下而排出來的架構，然後想到應該貼到 hackpad 上再繼續整理而成的。
但自我剖析一下，會選擇這樣的架構，我猜想有可能是因為我個人不喜歡「第一句話就道歉，後續也不說明當初為何如此作為」的人，因為我對此的判斷是「沒有設法預防事件再次發生的可能性的誠意」。
(是，所以上文我會把重建現場（代表理解受影響者之感受）排在第零句話。)
但不知為何我覺得好像應該再強調一下，我完全不認為上述「行為發生之過程剖析」可以作為「受影響者理應接受我的敘述架構並不對此感到生氣或認為沒有誠意」的理由，也不排除「在敘述架構順序之外還有其它可能原因」的假設。
當然。:smile:
然後我回想起在我印象中與 summit 的第一個接觸，是某次萌典松併啥密松時，hc 半開玩笑的跟我說：「這裡有個好大的直播坑......」（原句或第一句不記得了，但我目前的主要印象是這個）（我完全不同意，這表示主辦方已知此事、或我已是工作人員身份... 等，將我在 summit 的行為合理化的任何解釋）
當時好像連 summit 的日期（或工作安排時程）都還沒確定，我只說：「檔期比較確定了就趕快跟我說，因為我也要排打工這邊的檔期，不然就當天我再看有什麼可以幫的就盡量幫。」（這邊一樣是印象，不是原句）
11/08 早上，我一邊幫打工客戶救火，一邊看到直播不順時，會決定趕緊拉一板車加一箱器材到現場去支援，萌典松時與 hc 的那段（印象中的）對話，是很重要的原因。所以我剛才在想：「哇，能把這麼簡單的事情，搞得這麼麻煩＆惹人嫌，我也算是有特異功能了吧！」
11/09 最主要牽涉到的兩位朋友（資訊所技正、東翔導演）和 11/08 攝護線的工作人員不同，他們受影響時並沒有平日的默契和溝通管道可以疏散，而是集中到主辦負責人上。我想這是簡繁轉換的關鍵（之一）。
但除了對「情理之中」的發展，表示感到「意料之外」之外，不諱言我也在 g0v 與其它社群中，看過不少次類似「好心辦壞事」的狀況。當然這種情形在有明確上下層級指揮鍊的公司、政府部門裡面也很常見，但在主觀動機與客觀評價之間的落差，在我的採樣與解讀中，卻是開放社群中所發生的落差，遠大於在公司、政府部門中發生的落差。
在等 bp 打字時，再補充一下：科層架構裡的客觀評價，往往不會即時讓當事人或公眾知道 XD
我也補充一下，我說的「大於」主要指涉評價落差程度，並非數量，也考慮了延遲或間接轉述時，常造成的較和緩的感受。
:+1:
這次我終於知道為什麼，我覺得需要強調一下：我認為在 11/08~09 兩天中，因為缺乏與主辦方溝通造成的各種困擾，都應歸責於我的過失與疏忽；但另一方面，我以為大家能夠瞭解，我並非故意造成這些困擾。
下文的討論裡，在我看來大家都瞭解你並非故意造成困擾。
即使是我認為最重的一句「（或顯然目前看來你的界限和其他人不同）」也排除了故意。
瞭解，我也這麼認為。所以我沒有寫「誤」以為，但說「猜測」太弱，「相信」又太強了，一時沒想到怎麼措詞，剛好在這裡喘口氣讓你擔心了一下 XD
在這兩條脈絡底下，我非常非常在意，如何設法盡可能防止這種非故意的過失，或至少如何降低因此造成的「對個人情感的、對社群參與者之間關係的、對（非）組織事務運作的、對推廣開放文化的」傷害與障礙，讓開放運動參與者不再是（至少不是那麼快的）消耗品、讓 fork 社群不再只是因為互看不順眼而自立山頭。
我必須承認，在寫下這個 pad 最初的全文時，腦袋裡對這件事關注的程度或花費的時間，幾乎要比「取得概括承受不良結果的主辦負責人的諒解」更多。（寫到這裡，我猜這也是讓人覺得字裡行間感受不到誠意、覺得我在硬凹的，非常有可能的原因之一）
但除了再次表達我對「欠缺與主辦方溝通的行為、與因此造成的所有困擾」的抱歉之外，我還是想要提出，我非常不希望這些非故意的過失，以簡單的道歉作句號，用額度終究有限的人情或友情存摺，代替溝通協定或防呆機制，來承受這種「意料之外」、消化這些「好心辦壞事」的認知落差。
當然是這樣，不然大家也不會響應你的號召，壓縮出國收行李和睡眠的時間，就溝通協定與機制的主題，共筆打了一萬多字... 要不要整理一下來個短講啊？XD
果然時時不忘推坑 XD 我有種小學生在老師眼皮底下寫作文的惶恐感，（「摺」要罰寫一百遍！）不過我非常喜歡可以即時得到有用意見，所以在不要太過度壓縮出國收行李和睡眠時間的前提之下，請用力繼續啊 XD
為了解釋一般常識花這麼多時間，看到「請繼續」，還是頗無言。
剛剛在別的地方繞了一下，要出國收行李的是 ipa 跟 clkao？當時我以為是 au，「請繼續」也是指我邊寫 au 邊補充，看來又表錯情了
所以拿這種想法「往前解讀、往後推測」我的行為與行文，除了盡量設法表達誠意和取得諒解，並試圖強調我並非想以此合理化我的過失（或說硬凹）之外，我想我還是不會縮減這部份討論的篇幅，如果確實因此造成不快的感受，我現在只能想到先說聲抱歉；然後不小心又寫了很長的小結，就請當作 BP 這台不夠人性化又有失精準的機器的使用說明書吧！:heart:
這邊是不是要打上一個「全文完」啊 XD
對人的部份，如 ET 提議下次大松可以跟主辦人找技正取得諒解與確認，這部份已詳細討論，以下純就事來說。
你文末說的「在資訊源頭分流管理」是正確的想法，也已經實行了：此次專案 task force 的溝通不放在 g0v hackpad，而是在 slack 和無線電裡進行（這兩個工具的限制也有許多事後檢討，見其他 pad，此不贅）。
依慣例，列在 g0v hackpad 的內容全都歡迎共筆，更動時不需要先問過誰。但當內文的能指，指涉特定專案所規制的空間時，則於該空間中，特定專案的既成慣例應先於 g0v 社群平台的慣例。專案無明文慣例時，可聯絡主揪（專案發起人、空間維護者）以確定之。
如果主揪是我，可不用詢問直接套用「額外環節需確認/缺少環節逕補上」的模式，主揪是其他社群朋友時，則建議用頻寬較高的方式預先瞭解。以上全文完。XD
謝謝 au 老師批改！（立正），我等睡飽腦袋清醒了，再仔細想一想整個來龍去脈...
資訊所會議室，分接投影訊號
- 11/09 早上 Clay Shirky 的 keynote 之前，為了配合講者習慣與接線乾淨考量，我把 VGA 分配器，接在筆電→轉接頭→VGA訊號線之後（位於講台內）的位置，卻沒先向資訊所方溝通好，我對因此造成的所有困擾感到非常抱歉。
重點是需要先與主辦負責人溝通，而非執行細節。相信大家去 Bookshow 參加活動也不會逕自動用設備。同理。
造樣造句或許能讓你體會這件事的荒謬：下次我去 Bookshow 參加萌典松，在BP電腦灌遊戲打，因為我是自主參與加上自己覺得對活動有益。在這之前我覺得沒有必要知會BP，因為是 Bookshow 的防呆機制不好。
總之，沒有主動達成充份溝通是我的問題；就這次案例而言，我有其它認知上的疏忽之處導致這個問題，並沒有故意冒犯之意。
但以荒謬性而言，我想借用 clkao 的烤爐說，提出一個更貼合情境的敘述：某次萌典松併超農域松有現場作菜的單元（奧客麵還真的煮過 XD），你帶著燒烤爐來到現場，取得農域松作菜單元現場執行者同意後（但沒問到主揪奧客麵、場地主 BOOKSHOW），現場架起燒烤爐作烤肉（在該單元現場執行者全程陪同下、且主揪或場主路過時能夠發現並提出阻止）
我想這樣會更貼近狀況一點，歡迎接力寫故事。
- 未來如果有同樣情境，我會把器材接在更前端「轉接頭」的位置、使用牆壁而非講台內的插座，避免打開講台櫃門、造成影響器材的可能性。
重點是需要先與主辦負責人溝通，而非執行細節。
未來若我同樣想灌遊戲在BP的電腦中，我會灌在D槽，而非灌在系統槽。
- 為了盡可能避免造成困擾，我想確認一下未來的執行細節：如果用上面這種接法（相當於一個比較大台，但非 apple 品牌的轉接頭／訊號轉換器），應向統籌或場地方溝通哪些項目？例如... 講台外的筆電與轉接頭，是否有品牌、型號等等限制？轉接頭跟 VGA 訊號線插拔之前，是否需要先向場地方確認？
事先與主辦負責人而不是跟場地方溝通，除非你本身是主辦。這只是很基本的原則。
- 這條是附帶資訊：外場出租業（音響、燈光、投影機等）常以「是否有掛鎖頭、貼膠布（但不需要真的上鎖、封死）」為「是否需要向場地人員溝通」的判準；所以建議資訊所方考慮在講台門上掛個鎖頭，可以降低被更動到器材、造成困擾的機會。
正常情況下會先詢問主辦再動設備。
資訊所場地僅能由所內借用，一般所內人員僅借協助十分信賴並有基本禮儀常識的朋友借用場地。
如上面第三點所提的，我願意向統籌和場地方作各種詢問或溝通，以後也會這麼作。但當天現場 clkao 向我提到應和場地方確認技術細節這件事，所以寫下這些技術細節方便詢問，沒有打算略過主辦方的意思。
亂入 XD 還是建議事先講一聲啦，當天我們已經請兩組人拍攝跟直播，在講者臉上打燈會影響所有機器，會議室中間多架的設備也會擋住別人的鏡頭，這些只要先跟我們說，其實都可以事先安排的
我在這個段落很強調「如果接上一個比較大台的轉接頭」，原因是我在過去幾次黑客松期間，不只一次看到講者（或會眾）主動掏出（apple 與其它不同品牌的）轉接頭，接在講桌上的 VGA 線與筆電之間（其實在 BOOKSHOW 辦的萌典松也有過）。
如果這種行為是沒有疑問＆不受譴責的，那也許我以後要主動接上、被動提供同位階器材的時候，就不用太過擔心這是違反規則的事情。
當然我同意也願意向主辦或場地方溝通這件事，但我在這裡想弄清楚的是「界限在哪裡」（例如牆壁上的插座、講台上的訊號線，訊號線前的轉接頭，這些是常沒有向主辦方確認的項目）
界線在於，你不是 summit 工作人員，也非主辦單位，而是報名活動的會眾/參與者。這是有預算有規劃有時程的專案。這在通篇共筆已經說明多次。
以 11/08~09 這兩天的事情，我已在這個 pad 開頭的小結表達「非工作人員」的歉意，我在這裡想弄清楚的是未來的界限。所以詢問轉接頭與筆電是否有品牌或型號上的限制，以更精確界限在哪裡。
1. 是否為講者要求協助 2. 是否有其他線路影響其他人 3. 若不確定，可以詢問主辦人。禮儀/尊重的意思是：不要逕自 assume 「可能」影響他人的事情是 ok 的，跟設備無關。
先謝謝 ipa 與 clkao 提供了幾個明確的界限參考，我同意這幾個界限的考量、也願意遵守。但在我個人的解讀下，若要以最嚴格的角度遵守，會覺得有些滯礙難行，所以想說明一下原因，並詢問這幾個條款有沒有修改空間。
比方說，我作為會眾把筆電插上牆壁插座，因為供電迴路有功率上限，可能造成跳電影響同一迴路的使用者，如果因為這個不確定性要詢問主辦人，我個人願意配合，但自認為這不是一個很好的規範方式，可能會造成主辦方很大的負擔。
技術細節都是 case by case，凡事事先溝通就可以了說，我們可以一起去請教技正
如果把細節推到極端，認為插筆電插座也需要詢問主辦人，可能就本末倒置了。
我認為「開放參與、分散協作」要能夠 work、擴大參與，清楚而準確的規範是很重要的條件。當然 ipa 與 clkao 不是正在訂協作規範的律師，我也不是在挑語病、或要求你們理應如此作為；只是我個人，對於 11/08~09 的行為引起的後果感到非常抱歉（包含未經主辦方最高負責人同意，提供音源線分接頭、錄音機、錄影機、替口譯戴麥克風並拉音源線......等事），也對沒有自信能掌握基本禮儀的所有界限、可能什麼時候不小心會再次踩線感到非常不安，所以暫時採取最保守姿態、嘗試取得多一點關於界限的資訊來增加安全感。
是否需有明確規則、規則為何可能有待大家共同討論。但如果我到 bookshow 無法區分是否可以用燒烤爐烤肉、直接更動音響設備、或者把電腦插上插頭之間的界線，我會問主辦人。
是的，以上就是我正在進行一個詢問主辦人的動作 XD
我是說當場。
11/08~09 沒有當場詢問我非常抱歉，我正在詢問未來的狀況
未來也是一樣，如果你無法自行區分他之間的差別，請問主辦人
呃，可能我沒有說清楚，不好意思讓你誤會。我現在沒有分辨「訊號轉接頭」等細節的自信，所以提出上面許多問題，想「提早」在這裡詢問主辦人相關事宜... 當然如果說「到那時候再來問」我也樂意接受。
「如果你自己沒有分辨不同情況的能力，也不確定，請就每個動作詢問主辦人」這樣夠清楚嗎？譬如我到 bookshow 我插電不會問，我要用燒烤爐會問，我要更動音響配線會問。我有自信作這樣的判斷，如果你對當場沒有，請你每個動作問主辦人。
如果 BP 無法判斷，日後活動會考慮發一張「筆電插電不需詢問，其他使用設備請詢問主辦人」的小卡給你。也許可以解決疑惑？
呃... 據我的不專業判斷，這邊好像有點對不上頻。我相信我沒有成功讓 ipa 與 clkao 瞭解我正在詢問什麼，有沒有人可以協助我一下？
我知道你在問界限在哪，我的意思是如果你無法判斷界限（或顯然目前看來你的界限和其他人不同），請就每個動作詢問主辦人。
我覺得自己正面臨「我正在詢問主辦人，但主辦人告訴我去問主辦人」的處境...
「如果未來我是活動的主辦人，請你每個動作問我」這樣夠清楚了嗎？
這個非常清楚，我在前面也表達過非常樂意遵守。我現在認為提早問這些準則細節，好像很難讓對方瞭解我正在問什麼，所以決定暫時放棄主動溝通這件事（如果有人可以協助我一下，還是非常歡迎！）
「如果你有自行分辨是否該問主辦人的能力，請自行決定是否該問」「如果你自己沒有分辨不同情況的能力，也不確定，請就每個動作詢問主辦人」
還是要說一下，很感謝 bp 第一天提供那個一轉二的 3.5mm 接頭，真是拯救了大家 XD 不過提供攝影機就太超展開了，如果界線常常跟大家不一樣，只好麻煩點多問多打聽囉
向 ETblue 確認一下，除了訪談部份之外，我在 11/09 被動借出一台錄影機給戴工作人員牌的攝護線組記錄 R101（後來好像拿去別間但我忘記哪間），這個部份也算太超展開嗎？
如果與分工確認的直播團隊（這次是攝護線）溝通並達成共識願意借器材，這是很正常的溝通程序。但紀錄片和場地借用的負責人沒有被通知到，我想這是這次問題的簡單成因。
借機器給攝護線也要給 bp ++ ，day 1 直播是攝護線全權負責，跟他們溝通非常正確 ^^
Day2也是攝護線負責 :cat2:
老實說... 其實我沒有先確認這次分工負責的團隊或人員是誰，就把錄影機借出去了...orz
關於場地借用（我推測是指投影訊號分接的事）的負責人沒有被通知到，完全是我的疏忽，自以為轉接頭等級的事情不需要詢問；
關於紀錄片的負責人（ipa）沒有被通知到，我感到非常抱歉，但與投影訊號分接不同的部份是，我以為與東翔導演溝通、由他決定如何承報就可以了，所以主要的錯誤、沒作好的地方在於「沒有確認該項任務的通報層級是否到達東翔導演就可以了，沒查出應該通報到達專案負責人層級，也就是向 ipa 確認」嗎？
我仔細確認上面這點的重點在於，如果錯誤之處在此，其實我未確認直播團隊分工與負責人是誰時，就先一次主動、後一次被動的提供了錄影機，至少在前一次也是犯了同樣的錯誤。
一般來說，在既有規劃中添加額外的環節時，需要確認的責任在行動方身上（例如你跟我說要加 one man crew，並且負責架設），而在支援既有規劃中缺少的環節時，需要確認的責任在被支援方身上（例如你提供 3.5mm 接頭給我，無論主動/被動），所以性質不同。（至少這是我的 mental model...）
呃，我連攝護線借錄影機是要「補上缺少環節 or 新增額外環節」都不知道就借出去了...
我看你的說明，推定攝護線人員是要補上缺少環節，但是如果有疑問（「這是一個 feature 呢，還是一個 bugfix？」），確實多問一句比較好。這也是我自己下次會改進的部份。
瞭解 au 的意思，但除了 au 的 mental model 之外，我也想瞭解這次 summit 主辦方＆紀錄片專案負責人下的判斷點是否在此？
外國講者訪談錄影
事件
其實我是 11/8 深夜在考慮 11/9 要作什麼時，才剛好在 g0v hackpad 逛到有要錄訪談這件事，並不瞭解全局狀況（例如拍攝計畫細節、由哪個單位統籌、負責人是誰...等資訊）
只有半夜先問了剛好看到 id 的 au，然後 11/9 早上得知現場負責人是東翔導演。
其實整場unconf負責人是我和clkao，這應該也不是很難取得的公開資訊。
這個資訊有同時給予 bp。全文如下（11/9 上午 8:20am）：
「請到二樓與東翔導演討論
這是太陽花餘款贊助的追加紀錄片組坑，ipa 主揪，pinky 徐東翔團隊執行。他們有燈、器材、控油，素材檔和最終檔都會由 ocf 以 CC By-NC 釋出
我自己來說，多一組機側拍，只要空間不影響應該是 OK
然後 keynote 聽完後有什麼想問 Clay 的也請午餐前補到 hackpad 上」
我想這部份的主要問題是中午 pinky 表示可行而進行實作討論時，我應同時在 slack 上知會 ipa 此一更動。
這確實是我的疏漏，非常抱歉，下次會記得。
au 你是保母嗎？什麼都要你傳話也太累了，高智商不是這樣用的好嗎 XDDD
主要是 bp 並不知道有 slack 編組的存在，而因為我脈絡溝通不全，因此 bp 以為 pinky 同意即可。（下同）
不管有沒有 slack 都有管道可以通知 ipa 的吧？不然我看怎麼寫個教學文件，教大家第一次找坑主就上手好了 XD
對，但因為我脈絡溝通不全，所以 bp 以為「只需要」取得 pinky 同意 + 將著作權讓與 ocf。教學文件是好主意。
呃，其實我不是認為 au 這樣說了所以覺得沒問題。當然我瞭解 unconf 最高負責人是 ipa 與 clkao，但在指揮通報方面應該報到哪個層級（而非凡事找最高負責人），我採取的是相信東翔導演的判斷；但現在想起來，當時我可以多問一聲「這需要再跟誰確認嗎？」
至於我事前在樓下遇到 ipa 時，還在忙別的事情所以沒想到；直到後來訪談開始後，ipa 上樓看到我，主動找我說到她不知道第三四機這件事、討論 CC 授權等等
我到場時已經開拍(!)，沒有時間更動。主動表示不知有第三四機。
所以中午時，參考早上分接投影訊號造成歸責不清困擾的經驗，我只帶了兩台錄影機、一台電動滑軌上樓，找到東翔導演溝通，取得其同意可留在現場，以「提供第三四機並服從導演指揮、不為這幾台機器更動原計畫配置、可熱插拔」為操作原則，這樣至少在錄製過程中 or 事後發現素材不合用，也都可以直接撤掉，不影響原錄影計畫。
作為自發參與者，我無從得知這件事還需要再向上報告＆具體應如何向誰報告，自認為在已知範圍内，已作到尊重原計畫的極限。但事後結果發現，「summit 籌委、unconference 統籌、拍攝製作人」皆未被通知到有第三、第四機加入，顯示仍有訊息鍊斷裂造成指揮鍊斷裂的現象。
這次活動有明確分工，以上bp所述資訊與實際工作狀況出入頗大。活動通知主辦組只有徵求延長線支援，並未徵求其他支援，如果事先溝通會免去不少困擾。器材設置與訪談內容安排不同，事先溝通有其必要。
上午的事我不清楚，但三四機對我來說是主動支援導演的器材和人力，只要授權比照導演進行，導演也認為可行，那麼事後知會即可，不會認為是指揮鍊斷裂的情形。
這和 Lucy 臨時決定不接受訪問，而要逆向訪問的情況相類，我僅是和導演討論，確定可行即進入錄製，也沒有向 Lucy 表示應先問過製作人再同意其請求。
這也和 Clay、Felipe、Matt 調換場次的情況相類，我同樣是臨場被口頭告知，並無事前溝通，我的感覺就是臨場視需要調度，當然若能事前溝通或者會有助於規劃，但此類調整仍屬尋常。
錄製素材的授權方式正在與開放文化基金會確認中，導演當天跟我說還沒有簽授權（？），但我的意向簡單來說，是以開放文化基金會為著作人，日後應以 CC BY-NC 3.0 授權釋出，對使用該素材之作品提供工作團隊名單時應列名。
CC 3.0 逕改為 CC 4.0 :-) 其他都和我的理解相符。
開放文化基金會提供和我確認中的是 CC 3.0，但我樂意採用 4.0。
OK, 那 ocf 方應可直接昇級。
待過劇組就會知道啦，拍片是分秒必爭的事，沒事千萬不要亂入啊很可怕的
由於這已是 ocf 專案，請直接和專案負責人討論其他人已事前決定的授權細節。我認為增加工作人員與 credit requirement 這樣的改變，和調換現場順序、訪談內容之類，並不是是同等級的異動。
我在現場並未收到 credit requirement 的更動意向，僅向 bp 表示攝錄內容需以 ocf 為著作權人，也已當場告知授權細節。完全同意這部份若有更動，需要和 ocf 方討論。
但現場增加設備與調換訪問形式，對我來說是同等級的異動。
理解 au 作為訪談人的角度，覺得異動都一樣是異動。
現場增加設備其實跟訪談很不一樣（牽涉鏡位和燈光與換場可能），中場導演有跟我詢問調整方式，我們以節省時間為考量，不作更動。中間也有因為設備密集導致已經開拍第三四機攝影手入鏡的狀況，這些都是增加設備前會在前製作業詳細考量的。換場與鏡位調整整體來說都會因此限縮，這也是後來沒有調整左右方向的部分原因，有點可惜。
理解上述情況。再次強調，在 bp 徵詢 pinky 是否能增加三四機和 one man crew 軌道設備，以取得額外的影像資料時，我並沒有意圖影響 pinky 是否要同意 bp 的提議。
如上下文所述，我有所疏忽、下次會改進的，是在 pinky 評估並同意後，作為錄影組在 slack 上的窗口，應主動知會 ipa 和 clkao。
bp 在樓下不是有遇到 ipa？自己說就好啦幹嘛凡事都要透過 au 啊 XD
主要是 bp 並不知道有 slack 編組的存在，而因為我脈絡溝通不全，因此 bp 以為 pinky 同意即可。
這個我在上一段對話串裡面回覆了，主要是我在「開放參與協作為基調」的錯誤心理預設下，對於「應該上報到哪個層級」採取「相信東翔導演的判斷」的態度，所以沒有主動再找其它人溝通。
溝通的核心在於誠意，道歉也是。請在這個層次上三思。
我覺得好像可以在這裡分個段，以下是在討論授權的事 XD （應與 OCF 討論）
抱歉不按時序來，問一下 ipa chiu 這邊的「應與 OCF 討論」是在回答我底下的問題，希望我不要與第三或其它方討論「我與 ocf 討論授權的經過與感想」的意思嗎？或者只是「授權簽署以 OCF 指定窗口為準」的意思呢？
如果不是ＯＣＦ委託的拍攝者，第一個要取得同意的對象不是被拍攝者嗎？
是啊，所以才會說 1. 捐機器要看導演肯不肯用，以及 2. 著作權要讓與給 ocf。
話說，自動軌道的攝影似乎也並不能聲稱著作權。
我還好奇一件事，為什麼要改授權方式？考慮是？我想知道的是ＢＰ的考量。
BP 沒有改，在 hackpad 上 4 那個字是我加上去的，已改正。
這裡有列出一些 CC BY-NC 3.0 TW vs 4.0 International 的考慮。
我個人在意的是 BY-NC Clarity about adaptations 和 A more global license 兩項。
先聲明一下，關於授權方式的決定，完全以與 ocf 方專案負責人討論為依歸；但我想在這裡討論「我與 ocf 討論授權的經過與感想」應該沒有問題？或者在某些圈子的禮貌與習慣預設下，不可以與第三或其它方討論授權事宜？我想先等等看有沒有人可以回應我這個問題 XD
建議睡醒之後另起一個次標，以免混淆（相對單純的）錄影設備的事情。這完全是基於精神衛生的角度建議的。XD
加入現有的專案，如果要改變授權方式，不是應該和所有參與者討論？ 上面的問題其實也只是基於參與者的角度想知道需要變更的原因？（不過好像沒有要變，是我誤會了。）
沒有要變。只是註記一下 Summit 錄影紀錄 Hackpad 與事前口頭告知，都完全沒有提到 CC 的版本號，因此我預設是最新版（4.0）而誤解了。合約上如果是 3.0 TW，自然以 3.0 TW 為準。
上文提議 ocf 可以主動昇級，純屬個人提議，不具法律約束力。
經過一段等待時間，基於我自己的認知，與參考 clkao 前面談論到「credit requirment 的改變」對「我與 OCF 討論授權之經過」的指涉之意，我判斷我應該可以談論這件事、回答 ISABEL 的問題，只要明確「授權簽署談判以 OCF 指定窗口之意思表示為準」，應該沒有違反作為立約一方應盡的義務或慣例。
首先回答 Isabel Hou 的問題，我在甫到拍攝現場，與 au 和 pinky 導演溝通時，還有 ipa 到達現場和我談論授權時，我都作出「配合工作團隊既有的著作人約定、CC 授權方式」的意思表示。
但後來 OCF 方提出要簽署的授權備忘錄中，有「素材應於拍攝完成後五日內，以 OCF 指定格式交付」等敘述，但正與我討論的交檔方式，可能要等待 OCF 方兩週以後才能執行；以及「工作內容包含前製協調」但我實質已未參與，這類（可能）已無法完成的敘述。
所以我提出希望能修正為更符合運作現況的敘述，並提供一版我的意向敘述，我相信主要授權精神與 OCF 原版本相符（以 OCF 為著作權人，日後以 CC BY-NC 3.0 TW 條款釋出）。
除了交檔與前製協調之外，主要區別在於我把影片製作的習慣寫進敘述中，嘗試作正式確認（針對該素材，或以 OCF 名義發表之使用該素材之作品，若有提供工作團隊名單時應列名）（我想 clkao 說的 credit requirement 變更，應該是指這個）。但我也表達並不堅持採用我的敘述版本（我心裡想的是說明意向有利溝通），歡迎提出調整意見。
BP的敘述明確說明了為什麼拍攝這件事，不適於當場自發性的參與。您當場在表示同意遵守工作團隊既有的約定時，其實並不清楚到底同意了什麼，以至於發現後續有無法執行的狀況，然後又得回頭過來改約定.......。於是花了大量的溝通成本。
我認為拍攝這件事，本來就需要周密的規劃，接受當場自發參與本來就有風險的 trade off，但現在我認為我過於樂觀的直接把風險提案拋給決策者去作判斷，如果以後有類似情況，我想我會盡可能多提醒幾句，但不會到「風險預告書」的程度。
但另一方面，我當場同意的是「工作團隊既有的著作人與 CC 授權方式之約定」，並非（當時似乎還沒寫成的這一份）授權同意書中可能帶有的其它條款敘述，且自認願意盡最大努力配合，所以評估至少在授權這一件事上的溝通不會太困難。
而我認為目前花的大量溝通成本，是我在把 summit 幕後工作當作鬆散開放參與的任務來作的心態之下，作了許多未經充份溝通的行動，因此造成的許多困擾。當然授權是其中一部份，但至少就可見的篇幅來看，我認為只佔了很小的一部份。
我想釐清這裡說“接受當場自發參與”的“決策者”是指？
我原文第一行是泛指拍攝情境（包含我自己的拍攝工作，或萌典松時也會有人跑來問導播很辛苦要不要幫忙）；第二行提到決策者，ISABEL 這麼一提，我認為原語境不太準確，但我想可以解讀為「我找到 pinky 導演，提出第三四機」還有「ipa 到現場臨時發現有第三四機，意外進入一個需要決策（而且沒有主動風險預告）的麻煩處境」這兩件事。
防呆機制設計
就這次案例而言，我認為在預設鬆散開放參與的資訊池（g0v.hackpad.com）裡面，需要一些防呆設計
呃，寫到結尾我想起來應該確認一下，我這個印象是否有誤？
如果有誤，這個錯誤印象是否普遍？不排除這才是真正問題的可能性
但即使如此，我認為以下的解法仍然有使用價值。
這個印象無誤，原本就是 ask forgiveness not permission 的地方。
Summit與其他社群活動不同，我不全然同意是ask forgiveness not permission.
上文「地方」指涉的是資訊池的 hackpad 共筆... 我同意 Summit task force 的編組文化與共筆有異。
hackpad 或 github 上 ask forgiveness not permission 完全沒問題。現實世界有很多事情是無法 revert 的。舉例來說：我不會帶燒烤爐去 bookshow 烤肉給大家吃，然後 ask for forgiveness.
當然。此一大段的 scope 是資訊池/共筆/特定網址（即 g0v.hackpad.com）。
下一大段處理的是在共筆中「指涉到」實體任務編組時的標示方式。
- 在資訊觸及可能的鬆散參與者之前，皆清楚標示該項任務（或其中哪些部份、或該任務所屬的上層計畫）屬於 task force 類型，以及相關的統籌或聯絡窗口
- 這次活動有許多管道可得知總召，工作群組聯繫方式，但沒有收到溝通請求。
- 讓所有正式參與者發現有自發參與者時，都知道應如何向統籌窗口回報、確認
- 工作人員招募有好幾波喔。如果想要加入，可提早報名。所有任務基本上都不是以開放認領的方式。
但這看起來執行成本不低，所以或者反過來...
- 在資訊源頭分流管理，例如新開 g0v-task-force.hackpad.com，以統籌指揮為預設值的資訊池，再把其中可開放分散協作的部份，依上面的原則移出到 g0v.hackpad.com
這我同意，此次各組也用 FB、Slack、無線電等頻道進行統籌協作，我想有放到 g0v.hackpad.com 上的部份原本就是同意開放協作的。
同意共筆開放協作，但不表示現場沒有分工權責。這次事件其實只需要基本尊重與溝通。
是。我請 venev bp simonpai 幫忙共筆要問 Clay 的問題（事實上全是他們提的），這部份我覺得無涉尊重與否。
關於溝通：多一組機側拍的想法，我當天早上才收到，當時有提供脈絡：ipa 是主揪，由 pinky 執行。
現在回想，確實中午 pinky 表示可行而進行實作討論時，應同時在 slack 上知會 ipa 此一更動。
但當時我已進入訪談 Clay 的準備程序，精神狀況耗弱，所以漏了這一步，非常抱歉，下次會記得。
感謝 au 說明，所以 ve+bp 當天才提出此行動，ok了解。
其實沒有那麼複雜吧，不管是什麼專案，要幹嘛先跟原本坑主說一聲就好啦，又不會少塊肉 @@
非常感謝 au 一天內作這麼多訪談（這完全不是正常該排的行程），還多負擔了現場傳達訊息的角色。:cat: :cat2:
是還好啦，我想 CL 上文說「au 作為訪談人的角度，覺得異動都一樣是異動」很準確。
對我來說，臨時加受訪者 (Code4HK +1, mySociety +2)、臨時把我沒有準備好問題的受訪者往前調 (Felipe, Matt)、臨時對調採訪/受訪角色 (Lucy) 這些更動，造成的精神壓力遠大於 bp 在三樓臨時架設設備。
也再次感謝 bp venev simonpai 在我無法良好處理訪問順序對調時，主動 cover 了提問的構思工作。
如果沒有他們幫忙的話，我想至少延後過的 Clay 場的訪問無法順利完成。:dog:
還好架設備只會對劇組造成壓力 XD
事實上最辛苦的 pinky 導演都沒有上來留言... 加受訪者和加設備，兩者受影響最大的應該都是他 XD
這樣也許會比較容易兼顧「開放鬆散參與＆封閉統籌指揮」兩種任務並存的協作社群。
但實際運作起來會不會有所不便，也許要請籌委們將這次執行經驗代入考量，會比較清楚
其實蠻無言的。
我還是要宣傳一下 fork 社群 XD 社群如專案，不爽就自幹，如果社群慣例常常跟自己格格不入，那就代表頻率不合，需要建立新社群啦！其實 g0v 對許多族群的人來說還是難以參與，fork 社群是未來必然的趨勢，我們可以一邊 fork 新社群，一邊一起來寫 fork 社群懶人包，一定可以讓很多人受用的 :3
pull request / patch / merge 也是常有的事情，fork太久很難merge，也是寫code很容易碰到的 :goat:
這次的 ocf 合作案我想是一個 branch，之前社群慣例需要調整之處都有 merge 到，所以還沒有到 fork 的程度。
希望不會到那個程度。:rainbow:
g0v 還是比較侷限在方法論，分散式也有他的限制，感覺沒辦法當推廣開源文化的 last mile，我是很認真希望有人可以 fork 社群，去做一些 g0v 沒辦法做的事情，但是大家還是可以一起共用 g0v 的工具，像是 g0v 跟 moztw 這種關係，moztw 的族群明顯就是 g0v 比較難觸及的，但他們去面對不同族群的同時，還是可以使用 g0v 的 hackfoldr 等工具。有 fork 社群才有健康的開源生態系！
是，在開源專案裡，fork+merge 是確保維護者和參與者良好互動的最重要機制。
但在開源社群裡，建立良好溝通的機制至少也同樣重要。引一段 David Eaves 在 Negotiation Unconf session 的發言：「[We] need to establish strong relationships and effective communication protocols at the outset of any project. Without it, whenever there's a negotiation, it will frequently result in people going to alternatives (e.g. I will leave), and much less likely to commit to something constructive (I will stay).」
只是原先對人的部份（補上忽略的尊重）和對事的部份（建立互信/溝通機制）混在一起，比較難理清楚，但共筆一整天下來，也滿清楚了。
是噢我是想說直接在社群外獨立建國就不用那麼高程度的共識了說，像是前端松獨立建國以後就可以去跟柯柯松合辦活動，又不會拖累到 g0v 這一整坨東西，對大家都方便……而且我在柯柯松對著 bp 的鏡頭誇口說 fork 社群是未來的趨勢，到現在都還沒什麼實證，希望有人趕快 fork 一個來讓我做業績（喂
樓上，洪偉其實fork了一個烙哲學(以哲普人文寫作討論的社群)，g0vus也算fork阿，所以已經是趨勢了 XD \ETBlue/神預測！！
業績達成！（？）XDDD
關於道歉與溝通的小整理
- Pomin Wu 在 Unconf. 的提案：http://youtu.be/YSsdzYci9zI
- （本pad）au, BP：重建現場、道歉、修正溝通程序、理清不確定細節⋯⋯等動作的呈現順序，若與眼前受影響者的期待有異（例如對方期望單純、直接、無其他附帶訊息的道歉），即使說者無此意圖，仍可能會產生「無誠意道歉、硬凹找藉口」等印象，導致接受道歉者的溝通情緒再度惡化。
我覺得你在此處的文字很有誠意重建現場、道歉、修正溝通程序、理清不確定的細節。只是呈現的順序次第往往相反了...
趕快趁機問一下，au 你覺得是一開始貼的全文有順序次第的問題，還是在 // 對話裡面也如此？
主要是一開始的架構，對話是順著架構展開的。
變成了「理清不確定的細節」->「修正溝通程序」->「道歉」-> (可能沒有完全)「重建現場」...其實這也並非無理（所謂 bottom-up 思考），只是或許與受影響者的期待有異。
嗯... 其實一開始的全文架構，也不是完全按順序寫成，是我寫了很長之後，決定調動整理一下而排出來的架構，然後想到應該貼到 hackpad 上再繼續整理而成的。
但自我剖析一下，會選擇這樣的架構，我猜想有可能是因為我個人不喜歡「第一句話就道歉，後續也不說明當初為何如此作為」的人，因為我對此的判斷是「沒有設法預防事件再次發生的可能性的誠意」。
(是，所以上文我會把重建現場（代表理解受影響者之感受）排在第零句話。)
但不知為何我覺得好像應該再強調一下，我完全不認為上述「行為發生之過程剖析」可以作為「受影響者理應接受我的敘述架構並不對此感到生氣或認為沒有誠意」的理由，也不排除「在敘述架構順序之外還有其它可能原因」的假設。
- nchild 在 Facebook 的留言：
- 雖然我是很喜歡解釋事物的，建議大家暫時略過過長的解釋性發言以及解釋性討論，過一陣子再回來看 Bropheus 開的 pad（儘管討論看來欲罷不能）。
- 事件發生的當下，其實當事人需要的只是感受被照顧而已，這不代表另一方解釋性言論包含的訊息不重要，但感受不尊重的一方，在接受理性解釋討論時，實際上可能還會被激怒（參見 Pomin unconf 提案的討論），照顧感受不是一時半刻就可切換，況且，理性上看來政治正確的討論會形成一種高度，讓感受尚未被妥善處理者被迫涉入，原先的感受就更難消除，其實，不只是唐鳳說的順序，處理時間最好也要錯開一些。
- Isabel Hou 的秘訣：字數要少、