本頁面包含 Google 技術文件季度接受的技術寫作專案詳細資料。
專案摘要
- 開放原始碼組織：
- Open Collective
- 技術撰稿人：
- Anna e só
- 專案名稱：
- 改善一般說明文件
- 專案長度：
- 標準長度 (3 個月)
Project description
第一印象 常見的情況是，說明文件頁面只包含說明，沒有相關媒體 (影片、GIF 動畫、圖片)，但同章節中的其他部分則有更完整的項目。舉例來說，「編輯集體」只包含說明，而「新增財務主辦單位」則納入相關媒體。
在我瀏覽的網頁中，沒有任何媒體使用替代文字屬性進行說明。缺少圖片說明會導致使用螢幕閱讀器的使用者，以及網路連線速度較慢 (可能無法載入任何媒體) 的使用者無法完全理解說明文件。
說明文件的部分章節會合併常見問題和操作說明，方便您瀏覽使用者介面，例如變更財務代管服務供應商。由於說明文件介面中沒有目錄，因此使用者如果知道註冊記錄變更的後果，且只想要客觀指示，可能會把說明文件視為冗長且有形的語氣。
雖然技術文件的用詞相當一致，但公開的格式指南對說明文件的撰寫方式說明太少。由於「貢獻」頁面提到技術文件的貢獻內容，Open Collective 和潛在貢獻者都會從更全面的規範中受益。
提案 我提議複習使用者說明頁面，重新思考使用者的呈現方式和目前的架構。
方法和時程 我希望與社群合作，透過不間斷的回饋週期，改善 Open Collective 說明文件。
社群連結期 (2019 年 8 月 1 日至 9 月 1 日)：認識 Open Collective 社群！訪問知名專案和新專案的活躍成員，詢問他們對說明文件目前狀態的看法 (報告 #1)。記下用於追蹤查詢和問題的所有內部系統，以及在 Open Collective 文件中記錄這些系統的程序 (報告 #2)。評估現行版本說明文件中的潛在問題，並準備解決問題的計畫 (報告 #3)。
9 月 2 日至 6 日：第一次提供意見回饋和調整週期，並將社群在社群凝聚期內所有的意見和建議納入考量。我們的企劃書可以開始執行了嗎？是否有任何內容需要變更？(報告 #4)
9 月 9 日至 20 日：使用說明文件中較少人使用的章節，開發概念驗證。公開風格指南的草稿 (報告 #5)。
9 月 23 日至 25 日：提交概念驗證以供評估 (封閉群組)。
9 月 26 日至 27 日：驗證概念驗證上線前，是否需要進行任何調整？是否需要更多時間？並據此調整。(報表 #6)
9 月 30 日 - 10 月 9 日：概念驗證上線。第二輪意見回饋 (公開群組)。
10 月 10 日至 15 日：最終概念驗證評估和調整週期。(報告 #7)
10 月 16 日至 20 日：活動休息 [1]。
10 月 21 日至 11 月 23 日：完成公開版樣式指南 (第 8 份報告)。將風格指南中的所有操作說明套用至所有使用者說明文件頁面 (報告 #9)。回報內容：評估所有已執行的活動，並提供社群進一步的建議 (報告 #10)。
您可以要求延長專案持續時間。
[1]: 在申請「Docs 季節」前規劃的行程。
成果 - 關於執行活動的十份公開報告 - 公開的樣式指南，可供 Open Collective 和外部作者使用 - 重新設計的使用者說明頁面