20141109 自發參與者誤觸非鬆散開放任務之自我檢討與防呆機制設想
編輯歷史
| 時間 | 作者 | 版本 |
|---|---|---|
| 2017-07-03 04:30 | r2 | |
顯示 diff- 20141109 自發參與者誤觸非鬆散開放任務之自我檢討與防呆機制設想
+ 20141109 自發參與者誤觸非鬆散開放任務之自我檢討與防呆機制設想
事件日期：2014/11/09 g0v summit unconference
（280 行未修改）
|
||
| 2017-07-01 15:31 – 15:32 | r0 – r1 | |
顯示 diff+ 20141109 自發參與者誤觸非鬆散開放任務之自我檢討與防呆機制設想
+
+ 事件日期：2014/11/09 g0v summit unconference
+ 敘述視角：Bropheus Huang 第一人稱
+ *文長慎入：本 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
+ *How to get people interested in things that they don't? (aka How to get people angry?)
+ *（本pad）au, BP：重建現場、道歉、修正溝通程序、理清不確定細節⋯⋯等動作的呈現順序，若與眼前受影響者的期待有異（例如對方期望單純、直接、無其他附帶訊息的道歉），即使說者無此意圖，仍可能會產生「無誠意道歉、硬凹找藉口」等印象，導致接受道歉者的溝通情緒再度惡化。
+ *我覺得你在此處的文字很有誠意重建現場、道歉、修正溝通程序、理清不確定的細節。只是呈現的順序次第往往相反了...
+ *趕快趁機問一下，au 你覺得是一開始貼的全文有順序次第的問題，還是在 // 對話裡面也如此？
+ *主要是一開始的架構，對話是順著架構展開的。
+ *變成了「理清不確定的細節」->「修正溝通程序」->「道歉」-> (可能沒有完全)「重建現場」...其實這也並非無理（所謂 bottom-up 思考），只是或許與受影響者的期待有異。
+ *嗯... 其實一開始的全文架構，也不是完全按順序寫成，是我寫了很長之後，決定調動整理一下而排出來的架構，然後想到應該貼到 hackpad 上再繼續整理而成的。
+ *但自我剖析一下，會選擇這樣的架構，我猜想有可能是因為我個人不喜歡「第一句話就道歉，後續也不說明當初為何如此作為」的人，因為我對此的判斷是「沒有設法預防事件再次發生的可能性的誠意」。
+ *(是，所以上文我會把重建現場（代表理解受影響者之感受）排在第零句話。)
+ *但不知為何我覺得好像應該再強調一下，我完全不認為上述「行為發生之過程剖析」可以作為「受影響者理應接受我的敘述架構並不對此感到生氣或認為沒有誠意」的理由，也不排除「在敘述架構順序之外還有其它可能原因」的假設。
+ *nchild 在 Facebook 的留言：
+ *雖然我是很喜歡解釋事物的，建議大家暫時略過過長的解釋性發言以及解釋性討論，過一陣子再回來看 Bropheus 開的 pad（儘管討論看來欲罷不能）。
+ *事件發生的當下，其實當事人需要的只是感受被照顧而已，這不代表另一方解釋性言論包含的訊息不重要，但感受不尊重的一方，在接受理性解釋討論時，實際上可能還會被激怒（參見 Pomin unconf 提案的討論），照顧感受不是一時半刻就可切換，況且，理性上看來政治正確的討論會形成一種高度，讓感受尚未被妥善處理者被迫涉入，原先的感受就更難消除，其實，不只是唐鳳說的順序，處理時間最好也要錯開一些。
+ *
+ *Isabel Hou 的秘訣：字數要少、
|
||