內容指引
本文件說明官方說明文件應包含哪些內容。以下列出幾項原則與建議，幫助撰寫易於理解的內容。
我們希望達成兩個目標：
設身處地為使用者著想。 我們應以讓使用者能輕鬆從文件中學習的方式來撰寫內容。
編寫完整的參考手冊 。 我們的目標不是教授程式設計基礎，而是提供 Godot 功能運作方式的參考資料。
指引與原則
下列是我們應盡量遵循的指引。這些不是硬性規定：有時某些主題需要打破其中一項或多項。不過我們仍應以達成上述兩個目標為優先。
撰寫完整且易於理解的說明文件
沒有文件就等於沒有這個功能 。如果使用者找不到某功能的說明與用法，這項功能對他們來說就不存在。我們應該確保所有 Godot 功能皆有覆蓋。
備註
新增或更新引擎功能時，說明文件團隊需要得知相關資訊。當你的貢獻被合併且需要文件時，請在 godot-docs 儲存庫建立 Issue。
請盡量讓說明文件**維持在 1000 個單詞以內**。若頁面超過這個上限，請考慮拆分成多個部分。限制頁面長度可促使我們精簡寫作，並將大型文件拆解，讓每頁專注於單一問題。
每個頁面或章節都應明確說明**要解決的問題**以及能讓使用者學到什麼。使用者需了解他們是否正在閱讀能解決自身問題的正確指引。例如，標題請不要只寫「訊號（Signals）」，建議寫成「使用訊號回應變化」。後者更能明確表達訊號的目的。
備註
章節標題過長會讓側邊選單變得冗長，導覽也不便。請盡量將標題控制在五個單詞以內。
若頁面假設讀者已瞭解其他 Godot 功能，請註明並連結至相關文件。舉例來說，若物理相關章節用到訊號，請標註「訊號教學」為先備知識。若先備知識超出本說明文件範圍，也可連結外部網站。例如於入門指引連結「程式設計簡介」，或於數學章節連結數學理論教學網站。
減輕認知負擔
降低閱讀說明文件時的認知負擔。語言越簡單明確，學習效率就越高。你可以透過以下方式達成：
盡可能每次只介紹一個新概念。
請如我們寫作指引中所建議，使用簡潔易懂的英文。
請提供一個或多個**具體的實際應用範例**。真實案例遠比使用
foo、bar、baz這類抽象變數名稱來得好。
雖然有些人能理解較複雜的語言或抽象範例，但你也可能因此失去其他讀者。通俗易懂的寫作與實用範例對所有人都有幫助。
務必**設想自己是使用者**。當我們對某事物已非常熟悉時，很多細節就會變得理所當然，但有些新手未必能理解。優良的說明文件應該從使用者角度出發，並以最直白的語言說明每個功能的用途與適用情境。
請回想你初次學習某個功能或概念時，最需要先瞭解什麼？有沒有遇到不懂的術語？哪裡讓你困惑？又是哪些地方最難掌握？你會希望有其他使用者檢閱你的內容。我們建議你在動筆前，先練習口頭解釋這個功能。
備註
具備程式設計基礎是使用 Godot 這類複雜引擎的前提。討論變數、函式、類別等是可以的，但比起「元程式設計」這類專有術語，更應優先使用平實的語言。如果必須用到嚴格定義的術語，請務必給予解釋。