事件日期:2014/11/09 g0v summit unconference
先強調一下,我現在認為最主要的問題,在於我把 2014/11/08~09 這兩天的活動籌辦與支援,當作是開放參與、彈性協作的項目,所以在很多行事細節上使用了錯誤的預設,造成很多不必要的困擾,這點我感到非常抱歉。
但另一方面,我認為這個事件反映出很多「不管是開放協作或指揮統籌,組織運作會面對的困難、魔鬼細節、可能的防呆機制設計」,如果簡單的以道歉結束、停止研究就太可惜了,所以我會繼續敘述相關的事情,先寫到這裡。
這則小結的標題,原本應該是 2014/11/13 03:46。
但從打下標題,到打下第一行之前的這十九分鐘,心裡實在是感慨萬千,不得不再次停下來,整理一下情緒。
當時我在這個已經很長的 pad 中,還有另一個地方,看到一些話。據我的不專業解讀,我相信原敘述者的意思是:我[寫在此處的文字裡]缺乏溝通和道歉的誠意,並且硬凹。
我相信原敘述者一定有這麼解讀、這麼認為的原因,所以我也很用力往前文去找、去回想,可能在什麼地方造成了這種印象,或者我沒有成功表達出我心中的誠意。但我沒有很明確找出來是哪些地方表達得不好,所以又轉個方向自我懷疑了一下:是不是我真的沒什麼誠意,所以當然沒表達出來;或以(我不太瞭解的)對方的標準來說,我自己感受到的這點誠意其實遠遠不夠。但這兩項在理論上都不是我(至少是現在)能夠準確衡量的標準,所以試了一會兒之後就打住了。
然後我回想起在我印象中與 summit 的第一個接觸,是某次萌典松併啥密松時,hc 半開玩笑的跟我說:「這裡有個好大的直播坑......」(原句或第一句不記得了,但我目前的主要印象是這個)(我完全不同意,這表示主辦方已知此事、或我已是工作人員身份... 等,將我在 summit 的行為合理化的任何解釋)
當時好像連 summit 的日期(或工作安排時程)都還沒確定,我只說:「檔期比較確定了就趕快跟我說,因為我也要排打工這邊的檔期,不然就當天我再看有什麼可以幫的就盡量幫。」(這邊一樣是印象,不是原句)
11/08 早上,我一邊幫打工客戶救火,一邊看到直播不順時,會決定趕緊拉一板車加一箱器材到現場去支援,萌典松時與 hc 的那段(印象中的)對話,是很重要的原因。所以我剛才在想:「哇,能把這麼簡單的事情,搞得這麼麻煩&惹人嫌,我也算是有特異功能了吧!」
但除了對「情理之中」的發展,表示感到「意料之外」之外,不諱言我也在 g0v 與其它社群中,看過不少次類似「好心辦壞事」的狀況。當然這種情形在有明確上下層級指揮鍊的公司、政府部門裡面也很常見,但在主觀動機與客觀評價之間的落差,在我的採樣與解讀中,卻是開放社群中所發生的落差,遠大於在公司、政府部門中發生的落差。
這次我終於知道為什麼,我覺得需要強調一下:我認為在 11/08~09 兩天中,因為缺乏與主辦方溝通造成的各種困擾,都應歸責於我的過失與疏忽;但另一方面,我以為大家能夠瞭解,我並非故意造成這些困擾。
在這兩條脈絡底下,我非常非常在意,如何設法盡可能防止這種非故意的過失,或至少如何降低因此造成的「對個人情感的、對社群參與者之間關係的、對(非)組織事務運作的、對推廣開放文化的」傷害與障礙,讓開放運動參與者不再是(至少不是那麼快的)消耗品、讓 fork 社群不再只是因為互看不順眼而自立山頭。
我必須承認,在寫下這個 pad 最初的全文時,腦袋裡對這件事關注的程度或花費的時間,幾乎要比「取得概括承受不良結果的主辦負責人的諒解」更多。(寫到這裡,我猜這也是讓人覺得字裡行間感受不到誠意、覺得我在硬凹的,非常有可能的原因之一)
但除了再次表達我對「欠缺與主辦方溝通的行為、與因此造成的所有困擾」的抱歉之外,我還是想要提出,我非常不希望這些非故意的過失,以簡單的道歉作句號,用額度終究有限的人情或友情存摺,代替溝通協定或防呆機制,來承受這種「意料之外」、消化這些「好心辦壞事」的認知落差。
所以拿這種想法「往前解讀、往後推測」我的行為與行文,除了盡量設法表達誠意和取得諒解,並試圖強調我並非想以此合理化我的過失(或說硬凹)之外,我想我還是不會縮減這部份討論的篇幅,如果確實因此造成不快的感受,我現在只能想到先說聲抱歉;然後不小心又寫了很長的小結,就請當作 BP 這台不夠人性化又有失精準的機器的使用說明書吧!:heart:
事件
其實我是 11/8 深夜在考慮 11/9 要作什麼時,才剛好在 g0v hackpad 逛到有要錄訪談這件事,並不瞭解全局狀況(例如拍攝計畫細節、由哪個單位統籌、負責人是誰...等資訊)
只有半夜先問了剛好看到 id 的 au,然後 11/9 早上得知現場負責人是東翔導演。
所以中午時,參考早上分接投影訊號造成歸責不清困擾的經驗,我只帶了兩台錄影機、一台電動滑軌上樓,找到東翔導演溝通,取得其同意可留在現場,以「提供第三四機並服從導演指揮、不為這幾台機器更動原計畫配置、可熱插拔」為操作原則,這樣至少在錄製過程中 or 事後發現素材不合用,也都可以直接撤掉,不影響原錄影計畫。
作為自發參與者,我無從得知這件事還需要再向上報告&具體應如何向誰報告,自認為在已知範圍内,已作到尊重原計畫的極限。但事後結果發現,「summit 籌委、unconference 統籌、拍攝製作人」皆未被通知到有第三、第四機加入,顯示仍有訊息鍊斷裂造成指揮鍊斷裂的現象。
我覺得好像可以在這裡分個段,以下是在討論授權的事 XD (應與 OCF 討論)
防呆機制設計
就這次案例而言,我認為在預設鬆散開放參與的資訊池(g0v.hackpad.com)裡面,需要一些防呆設計
但這看起來執行成本不低,所以或者反過來...
這樣也許會比較容易兼顧「開放鬆散參與&封閉統籌指揮」兩種任務並存的協作社群。
但實際運作起來會不會有所不便,也許要請籌委們將這次執行經驗代入考量,會比較清楚