🤯 OSCVPass 2025 年度意見蒐集

[toomore]

Hi 各位 OSCVPass 夥伴,

OSCVPass 專案也執行了好多年，2025 也即將結束了🤯，想要蒐集一下大家對於 OSCVPass 目前專案的感想、想法、建議、意見💡，不論是好的部分我們持續下去；需要改善的地方、在下一個年度調整，歡迎在這個討論串中寫下你的想法！

目前和各位分享 OSCVPass 專案網站正在調整的方向，近期已加入關於開源授權條款介紹、過往審核通過專案列表（整理）。後續也預計加入開源專案起手勢引導 ... 等，希望未來 OSCVPass 不僅僅只是申請證明為「開源貢獻者」的身份，還兼具新手教學的起點。

再給我們你的想法，感謝！

[skyhong2002]

留言測試（我很喜歡 OSCV Pass 目前還沒想到，有想法再補上來

[susutw]

👍🏾

[MrOrz]

OSCVPass 讚讚大推

我在想現在有 OSCVPass 資格的人可能大部分是不太需要新手教學的老屁股。關於加入新手教學的部分，感覺也要搭配「讓獲得 OSCVPass 的人變多」的配套，來建立新手教學的 audience XD

[denny0223]

有一些調整想法，和助理一起聊天整理了以下提案

---

一、為什麼想調整 OSCVPass？

目前 OSCVPass 的結果只有兩種：「通過」與「不通過」。這有幾個好處（簡單、清楚），但也帶來一些限制：

• 門檻感偏高：很多其實有實質開源貢獻的人，會擔心自己「不夠格」，乾脆不申請。
• 成果差異看不出來：所有通過者在制度上看起來都一樣，無法區分貢獻型態與專長領域。
• 活動主辦單位難以精準運用：像 HITCON 這類主題明確的研討會，如果只知道「你是 OSCVPass」，但不知道你是不是做資安相關專案，其實很難設計對應的回饋或票種。

我期待的是：

維持 OSCVPass 作為「開源貢獻者身份認定」的公共基礎設施，同時在其上加一層非常「極簡」的徽章／標籤，
讓更多人可以通過，但讓成果呈現更有結構、對活動主辦更有用。

---

二、核心設計原則

這份提案的幾個原則：

1. 通過門檻要友善，不走菁英制
   只要符合開源定義、有實質可查證的貢獻，就應該盡量通過，而不是把太多人擋在門外。

2. 差異化放在「標籤／徽章」，不是放在「能不能通過」
   身份認定盡量 inclusive，榮譽／分類放在上層做細緻化。

3. 徽章設計要極簡，避免讓志工和系統爆炸
   不做分數、不做段位制，只用少量分類標籤，讓審查負擔與溝通成本可控。

4. 標籤不決定資格，只是給活動主辦與生態系更多資訊
   是否通過 OSCVPass 只看貢獻是否符合開源定義與基本量，
   A/B 標籤只影響「哪些活動可能特別想找你」，不影響你是不是「開源貢獻者」。

---

三、具體方案：在通過者身上加兩組「極簡標籤」

1. OSCVPass 本體維持不變

• 核心仍然是：

  • 專案／貢獻是否採用開源授權？
  • 是否有實質且可公開查證的貢獻？

• 只要符合條件，就「通過」，盡量不要因為標籤問題把人卡住。

2. 新增 A 組：「貢獻型態」標籤（可多選）

A 組是在說：你主要是用什麼方式貢獻開源專案？

暫定四類：

1. 🧩 Code & Review

   • 程式碼、issue triage、bugfix、code review、測試等技術實作。

2. 📚 Docs & Localization

   • 文件撰寫、教學文章、API docs、翻譯、在地化等。

3. 🎤 Community & Events

   • 活動籌備、社群經營、行銷宣傳、場務、社群平台管理。

4. 📢 Advocacy & Education

   • 演講、工作坊、課程設計、影片／Podcast、倡議文章等。

---

3. 新增 B 組：「專案領域」標籤（可多選）

B 組是在說：你大概在做哪一個技術／議題領域？

為了控制複雜度，一年內先維持 5～7 個選項，不亂加。暫定：

1. Security / Infosec

   • 資安工具、漏洞掃描、CTF 平台、防禦工具、安全研究。

2. Data / AI / ML

   • 資料處理、機器學習、AI framework、資料分析工具。

3. Web / App / Backend

   • Web 前後端、Mobile App、API server、一般應用服務。

4. Infra / DevOps / Tooling

   • CI/CD、部署、監控、容器、Infra-as-code、開發工具。

5. Civic Tech / Open Data / Gov

   • g0v 類、公民科技、開放政府、開放資料應用。

6. Education / Learning Resources

   • 開源教材、題庫、教學平台、學習工具。

7. Other / General

   • 不好歸類或橫跨很多領域的，就放這裡。

操作方式：

• 審查者覺得沒問題就接受；覺得不適合可以改成較通用的選項（例如 Other）。
• 模糊個案不需要硬判，因為標籤不影響通過與否。

---

四、活動主辦可以怎麼用這些標籤？

1. HITCON 這類主題明確的研討會

• 問題：他們希望特別回饋「有資安相關貢獻」的人，但目前 OSCVPass 沒有領域資訊。

• 用法示例：

  • HITCON 可以規劃：

    • 基本條件：持有 OSCVPass（不區分 A 組）
    • 進一步條件：B 組包含 Security / Infosec 者享有特定票種／小型交流會優先。

  • 也可以辦「OSCV Security Roundtable」，只開放 Security / Infosec 領域的 OSCVPass 報名。

2. g0v / 公民科技相關活動

• 可以針對 B 組 Civic Tech / Open Data / Gov 的通過者，設計：

  • 公民科技主題的工作坊、黑客松；
  • 特別的 travel grant 或參與名額。

3. PyCon TW / 資料、AI 類研討會

• 若想鼓勵 Python / Data / ML 相關貢獻者：

  • 可以鎖定 B 組 Data / AI / ML 搭配 A 組 Code & Review / Docs；
  • 給予某些票種優先資格或專屬小聚。

4. COSCUP、SITCON 這類綜合性年會

• 根據 A/B 標籤給不同顏色貼紙，幫助同領域、同型態貢獻者互相找到彼此。
• 若某年會有特定主題，也可以對應特定領域標籤設計加碼回饋。

---

五、多方利害關係人的影響整理

1. 對開源貢獻者（申請者）

好處：

• 通過門檻不因徽章變高，只要符合開源定義、有實質貢獻就可通過。
• 透過 A/B 標籤，可以讓自己的貢獻型態與專長領域被更清楚辨識。
• 若剛好對應某些活動主題（如資安、公民科技、教育），有機會獲得更貼近專長的回饋。

風險／需要注意：

• 難免有人在意「我被歸在哪個領域／型態」，所以標籤定義要寫清楚，並強調標籤不代表價值高低。
• 邊界模糊案例（例如同時是 Data 又是 Security 的專案），要容許「不精準，但不傷害權益」。

---

2. 對活動主辦單位

好處：

• 終於有一個「結構化但不複雜」的方式，能從 OSCVPass 名單中挑出「和自己主題較接近的貢獻者」。

• 不用自己重頭審查每個人的 GitHub／專案，就能設計：

  • 主題相關票種；
  • 主題聚會、roundtable；
  • 特定領域的加碼福利。

風險／需要拿捏：

• 若某活動所有回饋都只針對某一兩個 B 組領域，其他領域貢獻者可能會感到被忽視；
  這需要由活動自己負起溝通責任，而不是 OSCVPass 幫忙背鍋。
• 活動需要了解 A/B 標籤的定義，學習成本略有增加（但比自己重建一套系統省得多）。

---

3. 對 OSCVPass／OCF 團隊

好處：

• 用極少的制度複雜度，換來更高的生態可用性，讓合作研討會願意更深度接入 OSCVPass。

• 可以在年度報告中更細緻地描述生態樣貌，如：

  • 今年有多少「Docs & Localization」貢獻者？
  • 有多少人專注在 Civic Tech / Security / Education 等領域？

負擔與風險：

• 審查志工需要在通過後多做一小步標籤確認，但比「段位制」「分數制」輕很多。

• OSCVPass 會開始握有「領域分類」的部分詮釋權，需要避免過度干預、避免分類膨脹。

  • 控制方式包括：

    • B 組領域一年內不大調整；
    • 模糊個案用 General 處理；
    • 強調標籤不影響通過與否。

---

4. 對審查志工

好處：

• A/B 標籤某種程度把原本就存在腦中的「印象分類」寫成明確欄位，反而有助於形成共同語言。
• 不必討論「誰比較強」，只需討論「他大概是屬於哪種型態／領域」。

負擔：

• 審查流程多一個步驟：在審完是否通過後，順手幫他確認 A/B 標籤。
• 偶爾會遇到申請者問「為什麼我是這個標籤不是那個」，需要有簡單、穩定的回應話術。

---

六、風險控制與實施建議

為了讓這套設計保持「極簡」而不失控，我建議：

1. 不做段位、不做分數，只做分類標籤。
   不引入 Bronze/Silver/Gold 或 Active/Lead，避免階層化壓力與治理複雜度。

2. A/B 標籤數量與選項嚴格控管。

   • B 組領域一年只做極少數調整，避免版本爆炸。

3. 對外溝通時反覆強調：

   • OSCVPass 通過與否只看貢獻是否符合開源定義與基本量；
   • A/B 標籤是幫助「活動主辦做更精準回饋」的輔助資訊，不是價值高低的排名。

4. 先試運轉一個年度，再檢討。

   • 例如 2026 年先導入這套極簡標籤；
   • 年底時收集審查志工、申請者、合作研討會的回饋，再決定要不要微調。

---

以上是我對 OSCVPass 「降低通過門檻 + 極簡徽章／分類系統」的提案整理。
目標是：讓更多符合開源精神的貢獻者被接住，同時讓成果的多樣性與專長領域能被看見，也讓合作研討會有更多工具可以設計回饋。

[joeangel]

我覺得未來 OSCVPass 如果能朝三個方向前進（降低申請門檻、建立公開交流管道、完善貢獻分類），會大幅強化整個生態的友善度與長期價值，也更貼近 OSCVPass / OCF 的長期方針。

以下內容經助理整理

---

1. 再進一步降低申請門檻，並提供更多實際案例（尤其是非程式貢獻）

目前申請者仍偏向程式碼相關，但許多非程式類型的貢獻：

• 活動籌備
• 行政支援
• 文件維護
• 翻譯與在地化
• 教育推廣
• 內容整理

都對開源社群非常重要。

如果能：

• 提供更多案例示範
• 明確說明「最小可接受貢獻」
• 讓不同型態的貢獻者看到可參考的寫法

就能讓更多人跨出那一步提交申請，也讓開源貢獻的多樣性更被看見。

---

2. 建議建立公開的 Telegram 群組（或 Discord / Matrix），降低疑問門檻、增加交流

目前資訊主要在官網與 GitHub，對第一次接觸的人來說：

• 不確定自己的貢獻是否符合
• 不確定申請內容應該怎麼寫
• 不確定證據要多詳細

如果有：

• 可自由加入的 TG 群
• 能讓申請者互相交流
• 能讓有經驗的人分享成功案例
• 能即時協助澄清不確定性

會大幅降低心理門檻，也讓申請過程真正變得「社群化」。

---

3. 有系統的貢獻分類（標籤／徽章），長期能形成可用的人才資料庫

這點在我參與審稿時的感受特別深。

貢獻分類（例如：貢獻型態 / 技術領域）不只是展示好看而已，
長期來看會成為很重要的 Contributor Pool（貢獻者資料庫） 基礎：

• 讓研討會更容易找到不同專長的貢獻者
• 讓 OCF 在人才培育、社群支援上能看清整體生態結構
• 讓貢獻者自己在合作、媒合、徵稿或活動中有更明確的定位
• 讓開源生態的缺口（例如某些領域缺乏人手）更容易被觀察到

這也符合 OSCVPass 長期方向中提到的「擴大開源貢獻多樣性」「降低行政門檻」「推動開源文化」。

---

之前協助 OSCVPass 的審稿工作，因此能從實務中看到申請者卡關的地方。以上內容是根據我的觀察，再由助理整理後提出，希望能對之後的方向規劃有幫助，提供一些想法供參考，謝謝。