先針對 Mosky 的建議：
-
今年結果來看，reviewer 品質還是參差不齊，需要改善。去年的議程長並沒有交給我一個清單，所以問題在我們沒有一直維護 reviewer 的名單。
-
其實我有先看過所有的 comment，有砍掉約 5-10% 的評論，所以如果 mosky 連砍過的 review 都覺得有問題的話，代表一定有些 reviewer 沒有做好工作。這算是我今年沒有考慮到的地方，我本來是蠻相信所有 reviewer 的水準的，所以並沒有留時間 review reviewer 評論。這會是明年要改善的地方，我會在後文繼續說明。
-
今年是第一次嘗試匿名的 review，其實效果蠻好的。因為 review 的數量增加了非常多，這對審稿很幫助，今年每一篇都有 10-20 個人看過給予意見，這是往年做不到的。雖然沒很正式的實驗過，但我認為審稿時加上自己的名字的話，review 數量會變少。爛 comment 應該是我這邊要審過，好的 comment 我還不確定怎麼做，但之後網站有加個讓 speaker 能 reply/rebuttal 的欄位的話，也可以達到這個效果。怎麼實作可以明年再討論一下。讓 reviewer 選擇要不要加上自己的名字也是選項之一。
-
我今年會整理，提供之後議程組參考。
-
這也是今年沒有做好的地方，我是真沒想過 comment 可以這麼糟。
今年一共有 1,100 次 review，不過我到現在只來得及看內容，還沒看這些 review 是誰給的。所以名單需要一段時間，等我比較有空才有辦法整理出來，到時候會再發一個檢討報告給 reviewer。總結一下今年的狀況，reviewer 人數變多，review 次數增加，但爛 comment 也增加了。就先針對最嚴重的問題：
- reviewer 的能力
- 爛、文不對題、不知所云等 comment
首先 reviewer 是怎麼產生的？底下是我寫在議程組的討論串：
參加過去年的 review，基本上一個人大概能看 10 篇左右的 proposal，其實平均起來會稍微少一點。如果一篇 proposal 至少 3+ review，共總 80 篇的情況下，保險至少要 30-40 個 reviewer。數量有點多。
我對於 reviewer 的要求反而不是他/她 Python 有多厲害，而是
- 具備批判性思考 (critical thinking)，能夠針對不同 proposal 提出不同的評論
- 在審稿的期間有 足夠的時間 來審稿
第 2 點是有客觀標準的，所以在招募 reviewer 時就以此為基準：
A. 必須在審稿的兩階段，皆能抽空審稿。即至少審稿兩次。 B. 請盡量完成 8 篇以上的審稿。 C. 根據以往經驗。這幾周內，請安排總共 2-3 小時的時間來審稿。
所以只要該人 有空審稿，我就歡迎他加入。當然他需要對 PyCon 議程有基本的了解，如果從來沒參加過 PyCon 不能擔任 reviewer。
第 1 點我傾向透過 circle of trust 的方式來達成。也就是，我先邀請一些我相信具備 critical thinking 的 reviewer，然後請他們推薦人選，相信他們推薦的人選，再邀請他們加入。所以 reviewer 有兩種情況：
統籌人 —know—> reviewer 統籌人 —know—> inviter —know—> reviewer這樣有個額外的好處，之前都是透過 program chair 下去找，但我覺得每個人認識的人、領域、地理區隔有限，用這種方法能建立更多樣的 reviewer pool。對於議程組來說，主要確保能掌握所有 reviewer 人就不會有問題。原則上審稿人員招募就是這樣。
在信中也有提到，很重要的因素是 reviewer 有沒有空看。其實，多數有經驗的 programmer 都以太忙為由拒絕審稿，或根本就不理邀請人。
所以我最擔心找不到足夠的人審稿，我反而還無法顧及到這些人的能力。我沒辦法邀到這麼多人來審。於是我找了幾個我相信的人一起來想 reviewer 清單，最後我們準備了 50 個人的名單，裡面有 33 個人約 7 成的人答應。如果除一下總共 review 的次數，平均一個人看了 33 次（今年 review 分兩個階段，所以差不多就 20+ 篇）。每個人其實多看了很多篇，我不太確定為什麼比去年多了一倍的量。要在 PyCon 看 20 篇 proposal 不是一件簡單的事情，這人要接觸很多 Python 領域才有辦法看得懂 20 篇以上的投稿。所以我懷疑有些人以為看越多越好，但我們並不鼓勵這麼做。這應該寫在下次的 review guideline 裡，大家應該只看「有把握看懂的 review」。
既然我們只找了 33 個 reviewer 都有質量參差不齊的問題，短期內可能無法用 reviewer 的質量來邀，必須做好一定會有一些莫名其妙的 review 的準備。這部份建立黑名單也許有幫助，但我覺得那些表現不好的 review 也只是那個 reviewer 倉促審稿的結果，倒不一定是他沒能力。因為今天你投的稿是需要很有經驗的 Python 人能有資格審的，所以這些問題就曝露出來。在簡單一般的 talk 裡，或者說在 reviewer 平均水準以下的 talk 來說，多 reviewer 就很有效果。可以讀到很多面向的意見，講者也認為回覆有用，會設法根據意見改善自己的 talk。
“Thanks for all the reviewers' comments so I could further enhance my topic!”
“[…] Got it, and learn much. This year there seems more reviewers' feedback than ever.”
不過顯然我們審到比較難的稿件就曝露出自己的無知。這部份只能靠大家自己經驗的累積、找到更有經驗的人來當 reviewer。
再來是針對 review 的 comment。這部份根據今年的審稿注意事項，其實非常短：
- 評分時給予建設性的回饋有助於評分的收束，並讓投稿者有所成長。
- 稿件有分三個不同的 Python 難易度，請根據對應的難易度來審稿。難易度的判斷可以參考官網《如何設定投稿的 Python 難易度？》介紹。
- 即使匿名，請尊重投稿者並遵守大會的行為準則。
我以為這樣夠了，但很明顯很多人不懂「有建設性的回饋」是什麼意思。這部份我認為是缺乏代表性的例子，導致大家不清楚怎麼審。加上第一階段審稿時是看不到別人的評論的，但第二階段很多人都跑掉了沒來重看一次 review。好在要改善 comment 是做得到的，就多列舉一些例子讓大家參考，說明好跟壞的例子就有辦法避免。我今年會整理一份，希望對明年有幫助。
但即使這樣，還是會出現所謂「文不對題」、「不知所云」的 review。該人理解 review 的方式有誤，不論是他看不懂或誤解。這個最直接的辦法，是讓 reviewer 和 speaker 直接溝通，雙方都能了解對方的意思。但這個實行上會非常耗時且耗力，今天 TP 提了一個用 email refer（像 github issue 回覆）這樣的機制讓雙方交流，但我擔心有多少人願意花這麼多時間做到這件事。所以另外一個方法，就是找幾個人來看一下每個人的 review，這些人就要足夠資深，至少他要有辦法判斷每個 comment 的「正確性」。這個今年做非常少，幾乎沒有做，在快要公布結果前我有想討論，但並沒有人回覆我，也沒有具體的方案出來：
我自己也覺得有些評論沒什麼建設性，例如：「This is better to be a tutorial/workshop」，但並沒有提供理由。這樣無法幫助到投稿者的回覆，整理給 submitter 也不會有正面的影響。因為本來就有些回覆有勾選不提供給講者的選項，他們會呈現為：
Reviewer #01 (Vote: Strong accept) ————————————————— (Reviewer opted not to disclose)我想有兩個方式可以解決：
- 比照上述的方法關掉這些 comment
- 比照上述方法，但改為 (Review committee find the comment not constructive)
做法 1 比較省事。做法 2 submitter 想知道可以再寫信跟我要，但這會增加額外的負擔，例如為什麼不直接刪掉這個 review 就好等等。
我覺得會出現這些 comment 的原因，在於我們沒有提供所謂「好的 review comment」的範例。所以等最近事情少一點之後，我會整理一些範例，提供下屆在審稿時，寫在 review guideline 的參考。
如果把那些我稍微覺得怪怪的 review 全部都拿掉，這樣就省掉所有麻煩了。我也決定對剩下還沒寄出 decision 的 proposal 做這種事。這乍聽之下有點怪，但如果這讓投稿人生氣到明年不想再來了，那我寧可不公布。這無法治本，但應該是現在最能降低傷害的方法。治本就只能從 reviewer 再教育、review guideline 與範例、reviewer 和 speaker 雙方溝通來進行。
以上，是針對審稿現狀的檢討。
接下來，我想要提供另個觀點，解釋為什麼妳會收到這麼多妳莫名其妙的 review。從一個 reviewer 角度來看，他會收到像底下這樣的投稿：
蟒群之道
你已經投入多少年的時間在學習跟使用 Python？新的程式語言一個接一個冒出來，如果有一天 Python 像 Flash 那樣被作掉了，如何面對你逝去的青春？一個資深 Python 工程師，在這場演講中將不從 Python 作為一種工具，而從 Python 使用者作為一個軟體工程師的角度，探討 Python 如何能在台灣發展與茁壯。
- 問題意識
- 工程師的自我意識與職場倫理
- 團隊期待的工程師
- 產業與社會期待的工程師
- Python 社群可以作什麼
- 討論 Q&A
以及
Python 的 50 道陰影
你心甘情願的 接受了 Python 給了你的的束縛。
矇住雙眼的 Py2 Py3 的不同。
卡住你雙手的縮排
綁住你雙腳的 super
讓我們一個一個解開束縛，讓你重獲自由。
以及
大數據交友
在繁忙的工作中，與朋友之間的感情漸漸地疏遠，近期結交的新朋友也無力深入了解，不過隨著社群媒體的興起，改變人與人之間的互動模式，也透露個人的行為模式，在台灣，Facebook 甚至成為全球滲透率最高的國家，那面臨在 FB 上的龐大資訊，到底該如何萃取出與自己志趣相同的夥伴或是在朋友間成為不可或缺的存在？在演講中將介紹如何利用 Python 了解個人行為進而打入他（她）的生活圈當中。
妳覺得哪些演講適合 PyCon？
在我看來，三個都各有各的特色，如果能好好發揮都是很有趣的題目。中間那篇用了個電影梗，感覺有點來亂的，讓我有點擔心。
不過最後是中間那篇被接受了，另外兩篇直接拒絕。為什麼會這樣？原因是三篇中，只有中間那一篇很明確地提到與 Python 的關連：
- How to write a clean and good requirement/setup file
- a good package control mindset.
- make your code relocatable
- py2 py3 integration tips
- editor config so indention won’t bother you
- how python load package.
- knowing when to use ‘super’
- understanding the underlying scheme for some error prone python code:
- when to use global key word
- default argument problem
- Using tools to find error earlier.
其他兩篇，一篇沒有 outline，一篇 outline 沒有點明跟 Python 的關係。所以即使題目很有趣，也怕會不會到時候真的跟 Python 無關。但我必須說在內容有限的情況下，會越來越難決定。
這看個一兩篇可能還看得出差距，但當有 10 多篇這樣的投稿時，印象很容易受影響。最後你會傾向接受那些寫得很明確的投稿。然後在評那 10 多篇投稿時，就很容易受到彼此的影響，可能 reviewer 看到的稿件就跟本來投稿者的想法有偏差了。也許《大數據交友》真的會講分析社群網路的資料，也許他真的有辦法做到像他 abstract 所說的個人行為、生活圈分析，但看了很多投稿後就會覺得他做不到。
回到妳的投稿。這是一個關於 Best Practices 的分享。對於妳來說，這是多年使用 Python 的經驗的精華，要在 45 分鐘內分享這些經驗，本來就沒幾個人做得到。所以我認為這是一個很困難的題目，妳也花了對應的時間心力準備。我會建議在 outline 就直接把妳的心得寫出來就好了：
- 在命名中融入「提示」
- Exact. Ex. apple vs apple_the_company; name vs user_name, store_name
- Type Hint. Ex. page vs page_no; event vs event_key
- Verb. Ex. .json() vs .get_json()
這會多花你一些時間，但對 review 的幫助很大，你加了這些細節，就能跟其他的投稿區別出來。雖然你有把投影片附上，大家都應該讀過你的投影片了解實際的內容才對。不過我認為多一些 outline 還是有幫助，透過連結的檔案就變成很極端的結果，要嘛沒點都不知道，要嘛就把投影片全部看完。
實際上，這也是為什麼今年多了這麼多欄位的原因。我發現新手投稿在往年幾乎沒辦法上，因為他們看到沒幾個欄位，就傾向填得簡單一點，但在填的資訊不足的時候。底下是一個新人投稿，他講的主題應該誰都沒聽過，也沒有人認識他，但 review feedback 相當不錯，原因就在他提供了很多細節：
還在用過時的 OTP 保護帳號？來看看 FIDO U2F 吧！
密碼，是許多人帳戶安全的最後一道防線，但是僅依賴密碼的傳統登入機制其實既不方便又不安全。對此，很常見的一種補救措施是搭配 OTP 的兩步驟驗證，但它也有易用性與安全性方面的缺陷。由於種種因素，許多公司攜手組成了 FIDO 聯盟，希望制定一套安全、方便、通用、跨平台的標準，好好解決線上身份認證實務上各種縱錯複雜的問題。近年來 FIDO 聯盟的主要成果包含陸續被採納的 UAF 與 U2F 還有一組 W3C 的 Member Submission 文件。在這場演講裡，我將會分析常見的幾種身份認證機制之優劣，並著重於介紹 U2F 這套 Google/Dropbox/GitHub 等網站都已經採用的 FIDO 標準。日前我以 Python 實作了一套 no external dependency 的網站端 U2F 函式庫，所以我也會分享該函式庫的實作經驗與使用範例。如果您是一位網站開發者或技術愛好者，想要嘗試、採納 U2F 的話，本演講將提供給您足夠的基本知識與工具。
完整的投稿我放在另個檔案。
其實我覺得我大約寫到 80–90 分了 大家可以參考看看是我寫得有改進空間或真的部分 reviewer 有點問題
部份 reviewer 確實有問題，而因為我沒做好 review 的把關，所以讓這些不好的 comment 又流到 speaker 手上。我很抱歉今年又造成傷害，希望妳有看到 PyCon TW 改善的決心與努力，希望妳明年還能繼續參加。
這問題要由多個方面改善：加入審核 reviewer comment 的流程與機制、針對今年的結果增加更多指示與範例在 review guideline 裡、對今年無法做出有意義的 comment 的人，明年就不再邀請他、維謢一份 reviewer 清單，確保每年的審稿品質會提昇。
至於你的內容，我認為已經很完整了，如果能在大綱裡多加一些實際 Python 的例子能更快進入狀況。