GNU 網站管理指南

如果您有興趣自願擔任 GNU 網站管理員，請先完成GNU 網站管理員測驗。

順道一提，請編輯並改進這份文件！

[跳過目錄]

目錄

擔任 www.gnu.org 網站管理員

所有活躍的網站管理員都可以存取網站管理員 RT 佇列，這對應於電子郵件地址 <webmasters@gnu.org>。這是網站管理員的主要工作佇列。請定期檢查佇列，領取您可以處理的工單，處理它，並回覆訊息告知寄件者發生了什麼事，然後解決工單。請參閱下方RT 指南以取得更多詳細資訊。

所有活躍的網站管理員都應該是 Savannah 上 www 專案的一份子，以便可以提交變更。如果您尚未加入，請加入。大多數網站管理員任務都是透過在您的本機電腦上簽出 CVS 儲存庫、修改它們並提交結果來完成的。關於如何使用 CVS 的說明  （您需要的是「網頁儲存庫」）。

已變更頁面的通知會傳送到 www-commits 郵件列表。這是一個公開的郵件列表，因此任何人都可以訂閱和檢閱封存。

所有活躍的網站管理員都應該加入 www-discuss 郵件列表。如果您尚未加入，請寫信給 <chief-webmaster@gnu.org>。

計劃為網站撰寫大量新資料的網站管理員應提供著作權轉讓書。

如果您發現寄給 <webmasters@gnu.org> 的訊息您不知道如何處理，最好先忽略該訊息一段時間。但是，如果您注意到某件事已擱置超過幾天，最好在 www-discuss 列表上詢問：「有人可以教我如何處理這類訊息嗎？」

可以執行的請求

有時人們會發送電子郵件，要求我們連結到不同的軟體套件。在建立此類連結之前，務必檢查連結指向的頁面，並確保它沒有提及任何非自由軟體（請參閱我們的連結政策）。如有疑問，最好將您在頁面上找到的內容摘要發佈回網站管理員列表（但不要發給請求者！），並請其他人接手。

我們沒有連結到著名的 GNU/Linux 系統發行版網站，或著名的 BSD 系統發行版網站，因為所有這些網站都明確描述並促進存取各種非自由程式。

有時您可能會想重新安排層級結構、變更 CSS 格式、版面配置、標記或其他此類廣泛的事項。在執行任何類似操作之前，請諮詢 www-discuss 列表。

未經 GNU 翻譯管理員 <web-translators@gnu.org> 事先批准，請勿提交對與翻譯相關檔案（/licenses/translation.html、/server/standards/README.translations.html 等）的變更。

網站管理員組織

以下組織規則並非僵化；它們旨在為我們服務並分配責任，以避免事情被遺漏。因此，政策和升級程序不一定要完全遵循，但如果您不確定該怎麼做，最好遵循這些政策。

GNU 網站管理員群組由首席網站管理員 <chief-webmaster@gnu.org> 領導。

首席網站管理員負責確保最終處理寄給網站管理員 <webmasters@gnu.org> 的每則訊息。首席網站管理員不負責處理每則訊息；只是確保有人及時處理它們。首席網站管理員也負責培訓新的網站管理員，並盡力糾正處理不當的網站管理員電子郵件，必要時。

如果網站管理員不清楚如何處理特定問題，則應將訊息發送到 www-discuss 郵件列表，以便所有網站管理員都能學習如何在未來處理這些問題。

網站管理員離職

我們理解人們的生活會改變，並且我們知道您可能不想永遠擔任 FSF/GNU 網站管理員。我們要求您在想要離開時告知我們：請不要就此消失。

當您註冊成為網站管理員時，您承諾每週投入一定時數的志願工作。如果您需要將時數降到該水準以下超過幾週，或想完全停止擔任網站管理員，請在您的情況發生變化時盡快通知 <chief-webmaster@gnu.org>。

使用 RT

寄給網站管理員的郵件儲存在名為 RT 的工單管理系統中。此系統將有關特定問題的所有通信記錄在一起，確保不會遺失任何請求等等。本節記錄 GNU 網站管理員使用的慣例。

複製所有與 RT 相關的郵件會很有用：新工單、其他網站管理員對工單的回覆等等。這樣我們才能互相學習。如果您可以積極協助處理 RT 工單，請考慮這樣做。許多人可以為您設定 RT 帳戶，只需寄信給 www-discuss 即可。

RT - 快速指南

若要查看未結工單，請造訪 rt.gnu.org 並使用您指派的 RT 使用者名稱/密碼登入。（如果您沒有，請寄電子郵件給首席網站管理員。）您的 RT 首頁上會有一個連結到網站管理員佇列（以及許多其他項目）。看到列表後，按一下主旨連結將會開啟工單。

首先也是最重要的：運用您的判斷力，而不是盲目地遵循程序。如果特定工單上的操作因任何原因對您來說似乎有問題，請寄電子郵件給 www-discuss 或使用工單上的「評論」連結。話雖如此，大多數工單都屬於幾個類別之一，因此我們嘗試在此列舉常見案例。

RT - 通信 vs. 評論

您可以將兩種資訊附加到工單：通信和評論。

通信
將會傳送給發送初始報告的人。當您想取得更多關於報告的資訊、向請求者提供更多關於正在進行的工作的資訊、讓他們知道工作已完成等等時，請新增通信。
評論
僅由工單人員看到：擁有者和列為 AdminCCs 的人員。您可以使用評論來記錄關於工單工作的內部筆記。例如，如果您在將 RMS 的一篇文章轉換為 HTML 上做了一些工作，但還沒有機會完成，您可以新增評論說明您已部分完成，以便其他網站管理員知道不要處理它（請確保將工單標記為「開啟」）。只要原始請求者不需要看到，您就應該新增一些東西作為評論。但是，請盡可能將更多通信轉換為評論。

不幸的是，新增任一種類型通信的方法非常相似，因此很容易混淆它們。請小心。

除了透過網頁介面之外，沒有其他方法可以進行其他修改。但是，有一些巨集指令碼可用於修改在 Emacs 或 mbox 格式中收到的電子郵件。請向 www-discuss 查詢這些指令碼。

RT - 與他人協調

您通常需要詢問其他人關於如何處理工單的更多資訊。如果我們不介意向他們展示一些關於我們如何做事的內部資訊——換句話說，如果他們是 GNU 專案的朋友——最好的方法是寄郵件給他們，並將該郵件也作為工單的評論。

因此，舉例來說，假設您想詢問 RMS 頁面上的特定連結是否允許。您可以透過使用工單頁面上的「評論」連結之一來執行此操作，並在抄送欄位中列出另一方（在本例中為 <rms@gnu.org>）。您也可以透過發送具有如下標頭的郵件來執行此操作

    To: <rms@gnu.org>, <webmasters-comment@gnu.org>
    Subject: [gnu.org #1234] Question about link policy

1234 應為適當的工單編號。

前一種方法更萬無一失：RT 將變更寄出的郵件，使另一方看到的唯一地址是 RT 的地址，並且任何回覆都將保證進入工單（也作為評論）。但是，如果您主要透過電子郵件工作，則後一種方法也可以。

請注意，這不適用於其他由 RT 處理的地址。因此，如果您將 <campaigns@fsf.org> 新增到 webmasters 中已存在的工單的評論的抄送欄位，則不會有任何內容進入campaigns佇列。在這些情況下，請在您想要引起注意的佇列中建立一個新工單，並使用「參照」或類似的關係欄位來連結兩個工單。

RT - 工單狀態

new（新）
適用於尚未對其執行工作的工單。RT 會自動為新工單指派此狀態；無需明確設定它。
open（開啟）
適用於正在處理的工單。當新增評論或通信時，RT 將自動為工單提供此狀態；您通常不需要手動將工單變更為開啟。
resolved（已解決）
適用於問題已解決的工單。當您完成工單中概述的請求，或確定它不適用，或以其他方式處理它時，請執行此操作。在完全解決之前，請保持開啟狀態。
deleted（已刪除）
適用於垃圾郵件（且僅限垃圾郵件）的工單。此狀態由網頁介面中的「標記為垃圾郵件」選項自動設定，這是處理垃圾郵件工單最方便的方式。
rejected（已拒絕）、stalled（停滯）
不應使用。

關於工單狀態的其他考量

RT - 工單升級

如果您想處理請求但不確定如何進行，或者認為請求很重要且可能被忽略，請保持工單開啟，並寄電子郵件給 www-discuss 列表。

RT - 錯誤轉發的工單

有時人們會寄郵件給 <webmasters@gnu.org>，最好在其他地方處理。當這種情況發生時，您可以執行以下兩件事之一

1. 如果有適合該工單的 RT 佇列，請將其移動到那裡。

當移動錯誤轉發的工單時，最好通知兩個佇列的觀察者：工單從哪個佇列移動以及到哪個佇列移動（RT 不提供自動通知）。您可以透過在工單中使用 RT 網頁介面寫下評論，或透過將郵件發送到 <queuename-comment@gnu.org> 並使用原始主旨行，來同時通知兩個佇列。簡潔的訊息「已將工單 1234 移動到您的佇列」就足夠了。

2. 如果沒有適當的 RT 佇列，請將郵件轉發給適當的對象，並新增評論說明您已這樣做（如果合適，可以解決它）。通常最好不要透過 RT 抄送機制執行此操作。相反地，以一般電子郵件轉發訊息。

編輯與建立網頁

本節僅包含專門針對網站管理員的資訊。如需一般資訊，請參考GNU 網站指南。

若要在 gnu.org 的主要部分中建立新頁面，請使用樣板。  請勿從現有頁面開始。

注意：檔案名稱應僅包含小寫字母、數字、「.」和「-」（「_」可以接受，但不建議使用）。

網站結構與導覽

網站依主題劃分為目錄——有一個目錄用於 GNU 專案資訊和歷史記錄（「關於 GNU」章節）、一個目錄用於我們的授權條款（「授權條款」章節）等等。這些目錄中的每一個都有一個主要頁面，共享相同的名稱；例如，/gnu 目錄有一個頁面 gnu.html，它是關於 GNU 的主要頁面，因此應提供對該章節內所有資料的存取權限。請注意，哲學理念主要頁面與幾個子選單相關聯：/philosophy/essays-and-articles.html、/philosophy/speeches-and-interview.html 和 /philosophy/third-party-ideas.html。

主要導覽列僅包含主要章節的項目。因此，未列出的章節（例如，GNU 樂趣）中的每個頁面都應連結回其主要頁面，以便人們取得關於手邊主題的更多資訊。

章節內的導覽還有改進的空間。「教育」和「惡意軟體」頁面已經有麵包屑導航和側邊選單，但其他頁面沒有。我們至少應將麵包屑導航，以及可能的標籤，新增到「哲學理念」頁面。這是一項具有挑戰性的工作。如果您有興趣協助完成，請挺身而出！ :-)

將純文字轉換為 XHTML

偶爾，RMS 會以純文字格式寄送一篇文章給網站管理員，並要求他們將其放在網站上。純文字需要轉換為 XHTML 並放入我們的標準樣板。在進行轉換時，您應注意幾件事

撰寫與審閱惡意軟體章節的項目

如果您計劃為 /proprietary/ 中的頁面撰寫或審閱項目，請參考我們的提交指南。

每個項目通常至少屬於 2 個頁面，分別對應於它描述的惡意軟體的類型 (proprietary-*.html) 和來源 (malware-*.html)。新項目也應出現在 proprietary.html 中。為了簡化維護，新惡意軟體項目會寫入單一檔案 (/proprietary/workshop/mal.rec)，並透過指令碼 (/proprietary/workshop/item-create) 新增到相關頁面。對現有項目的任何變更都在 mal.rec 中完成，然後透過另一個指令碼傳播到相關頁面：/proprietary/workshop/malgen。

惡意軟體項目的新增和修改程序在惡意軟體操作指南 (/proprietary/workshop/README.md) 中說明。

惡意軟體章節中的頁面採用 創用 CC 姓名標示 4.0 國際授權條款。建立新頁面時，請牢記這一點。

請在 planet.gnu.org 上公告新的惡意軟體條目。請參閱關於在 Planet GNU 上發布的資訊。

在幽默或音樂章節中新增頁面

  1. 檢查建議的笑話或歌曲是否符合 RMS 的要求。如果不符合，請感謝提出建議的人，並禮貌地解釋為什麼它不能在 gnu.org 上發布。
  2. 如果符合，請取得明確許可，以在合適的自由授權條款下發布它。
  3. 在 /fun/jokes/ 或 /music/ 目錄中建立新頁面。
  4. 在 /fun/humor.html 或 /music/music.html 中新增指向新頁面的連結。

讓新頁面可見 - 在 Planet GNU 上發布

官方 GNU 軟體的網頁

GNU 軟體維護者通常透過向 Savannah 註冊其專案來獲得對其網頁儲存庫的寫入權限。（過去，他們向網站管理員提供要安裝在網站上的頁面，但這已不再是最佳程序。）

GNU 套件的官方首頁應位於 www.gnu.org 上，特別是在 /software/PROGRAMNAME 中。有時這些頁面不存在或已過時。如果維護者要求，網站管理員應協助建立或更新頁面。

您確實擁有從 Savannah 簽出任何 GNU（或非 GNU）網頁儲存庫並提交變更的技術權限。但是，套件維護者負責他們自己的頁面，因此除非其維護者要求您或確認特定變更，否則您不應修改頁面。唯一的例外是對於不影響意義的小變更，例如修正 (X)HTML 驗證錯誤、將頁面更新到最新的樣板、更換頁尾中錯誤的錯誤報告地址等。在任何情況下，您都應通知維護者變更。

連結

在新增或更換任何連結之前，請閱讀我們的連結標準。

請定期檢查失效連結報告並處理它們。請注意，網站管理員應僅修改英文頁面中的連結。

如果連結失效是因為頁面已移動，請嘗試尋找其替代頁面。如果您成功找到，請重新檢查該頁面，以確保它符合我們的連結標準，如果符合，則新增它。如果您找不到替代頁面，請移除該連結——如果它對頁面至關重要，您可能需要新增註解說明該資源不再可用。如果頁面不再符合我們的連結標準，您將需要做出判斷，並權衡連結的價值與其問題；您可能想寄郵件給撰寫包含該連結的頁面的人或 www-discuss 以取得第二意見。

如果您確實從我們不維護的頁面中移除連結——例如，由維護者保持更新的軟體頁面——請將問題以及您為修正問題所做的事情通知他們。

有時我們會被要求在頁面中新增連結。最常見的情況是請求來自 RMS，您只需新增連結即可。否則，有兩種可能性

連結到自由 GNU/Linux 發行版

對於 GNU/Linux 發行版連結的建議應按如下方式處理

  1. 請求者應為發行版的主要開發人員，而不僅僅是使用者。如果他們是使用者，請感謝他們，並請他們聯絡開發人員，以防他們想要被列出。
  2. 簡要檢查發行版是否為可行的候選者：他們應具有僅包含自由軟體的明確政策，並且應相當清楚如何取得來源以及包含哪些套件。如果這些事情不存在，請與請求者討論（禮貌地）。
  3. 如果沒有明顯的問題，請要求請求者向專用郵件列表 <gnu-linux-libre@nongnu.org> 請求背書。他們應包含其新發行版的描述、指向其首頁的連結以及任何其他有用的資訊。然後應解決我們的工單。
  4. 僅供參考：gnu-linux-libre 列表將從那裡接手。基本上，他們將詳細審查它是否符合我們的標準，如果一切看起來都很好，則將其轉交給 FSF 授權人員進行最終批准。

在任何情況下，網站管理員絕不應只是將據稱是自由的發行版新增到我們的列表。FSF 授權和 RMS 必須明確批准任何新增項目。

連結到 GNU & 自由軟體使用者群組

可以將 GNU 或自由軟體使用者群組連結的請求轉介到 LibrePlanet 網站。然後可以解決我們的工單。

鏡像站

GNU 鏡像站

當我們收到新增、變更或移除 ftp.gnu.org 鏡像站的請求時，首先請確保鏡像站符合我們的標準，如 鏡像站建議中所述；該頁面說明了我們要求鏡像站志願者提供的內容。如果有任何疑問，請在同一個工單上評論以徵求其他網站管理員的意見，或在採取任何行動之前諮詢網站管理員郵件列表和/或 <gnu-advisory@gnu.org>。

在確認鏡像站符合我們的列出標準後，請執行以下操作

  1. 編輯檔案 /prep/FTP（在 CVS 中）；它是純文字，而非 HTML。（請勿列出 ftp URL：此協定正在逐步淘汰。）
  2. 在 /prep 子目錄中執行 make。
  3. 如果該站台是否也可以作為其他鏡像站的來源的答案是肯定的，則將 rsync URL 新增到 mirror.html 中「鏡像 GNU FTP 伺服器」和/或「鏡像 GNU Alpha 版本伺服器」下列出的項目（如適用）。
  4. cvs commit 檔案 FTP 和 ftp.html，以及 mirror.html（如果適用）。在提交日誌訊息中，包含鏡像站的名稱及其位置，以及 RT 編號（如果有的話）。
  5. 更新 Fencepost 上的檔案 /gd/gnuorg/web/FTP.contacts，保持檔案開頭說明的模式。
  6. 請參閱下一個關於鏡像站狀態的條目。
檢查鏡像站的狀態

鏡像站只要保持最新狀態就有用。過時的鏡像站甚至可能有害，因為下載舊版本的軟體可能會給使用者帶來安全風險。因此，檢查鏡像站的狀態是新增/修改鏡像站過程中不可或缺的一部分。

「Mirmon 頁面」追蹤器（由 Savannah 維護）會顯示每個鏡像站上次更新的時間。當 Mirmon 報告某個鏡像站過期或無法連線數日後，請自行測試以確認情況是否屬實（Mirmon 可能有組態問題，或者鏡像站可能在上次探測後已更新）。然後聯絡其維護者，讓他們知道問題所在，以便他們可以修復。如需如何執行此操作的範例，請在 RT 系統中搜尋主旨包含「[Mirror Status]」的工單。RT #1817699 有一個關於如何測試是否可以使用 rsync 存取鏡像站的範例。

如果需要移除鏡像站，請檢查 /server/mirror.html 上是否引用了該鏡像站，並移除該條目。

網址 http(s?)://ftpmirror.gnu.org/pkgname（也由 Savannah 維護）在鏡像站之間進行多工處理，嘗試選擇一個位置鄰近且為最新的鏡像站。

鏡像站聯絡資訊

當我們收到與鏡像站相關的請求時，請檢查 Fencepost 上的檔案 /gd/gnuorg/web/FTP.contacts，如果聯絡資訊尚不存在，請新增；如果需要，請更新。我們缺乏許多較舊鏡像站的資訊，或者我們擁有的資料不是最新的。

非 GNU 鏡像站

當我們收到新增、變更或移除非 GNU Savannah 鏡像站的請求時，請寄送電子郵件至 <savannah-hackers-private@gnu.org> 並附上資訊。使用 -private 的原因是為了避免聯絡地址公開。如果鏡像站管理員的電子郵件地址未涉及，或者沒有其他隱私問題，最好使用 <savannah-hackers-public@gnu.org>。

www.gnu.org 的鏡像站

我們不再推薦或列出 www.gnu.org 的鏡像站。

其他常見請求

本節處理可能需要非顯而易見的操作，但在本頁面其他部分未提及的常見請求。極其簡單的請求，例如修正印刷錯誤或 HTML 格式問題，則不在此處記錄。

ThankGNU/ThankCRM

注意事項

如果您有任何疑問，或者您懷疑捐款可能有問題（例如，名稱不當），請在註解中提及，並將工單移至 campaigns 佇列。FSF campaigns 團隊隨後可能會透過撰寫註解並將工單移回 webmasters 佇列來協助您。

請求允許使用圖片

當有人請求使用網站「Art」區塊中的圖片的許可時，首先要做的是檢查圖片所在的頁面。大多數圖片都有明確的授權條款。如果請求的許可合理，但與該授權條款不符，請將工單移至 licensing 佇列。否則，請提醒他們注意授權條款。

如果圖片所在的網頁沒有明確的授權條款，且請求是明確的「是」或「否」，請直接回覆請求者，並參考 GNU 政策解釋決定。對於更複雜的情況，請將工單移至 licensing。

在考慮請求時，請謹慎行事。如果圖片的使用並非我們會連結的內容，例如，那麼這也不是我們應該給予許可的內容。在回覆任何請求之前，請隨時在 www-discuss 上討論。

將圖片新增到 GNU Gallery

  1. 當有人向 GNU 提供圖片時，首先要從作者那裡了解圖片是以哪種授權條款發布的，並檢查這是否為適當的自由授權條款。如果新圖片是另一張圖片的衍生作品，請確保其授權條款與至少一個父圖片發布時所用的授權條款相容。如有疑問，請在 www-discuss 上詢問。
  2. 使用瀏覽器的預設字型大小，在原始尺寸下檢查渲染是否足夠，至少針對作者提供的其中一個版本。如果不足，請建立一個新的版本以供顯示。
  3. 嘗試壓縮任何大型 PNG 檔案（數百 kB），例如使用 OptiPNG。
  4. 將圖片檔案安裝在 /graphics/ 目錄中，但除非絕對必要，否則請勿安裝非常大的檔案（2MB 或更大）；相反地，請要求作者將其上傳到尊重使用者隱私的託管設施，例如 Framadrive 或 Internet Archive。
  5. 在 /graphics/icons/ 子目錄中建立一個 80x80 像素的縮圖；這可以使用 mogrify 方便地完成。例如，要為 arantxa-glitch.jpg 建立縮圖，您將執行
    mogrify -resize 80x80 -background white -gravity center \
-extent 80x80 -format png -path icons arantxa-glitch.jpg \
&& mv icons/arantxa-glitch.png icons/arantxa-glitch.80.png
  6. 在 /graphics/ 中建立一個新頁面，使用位於 /server/standards/boilerplate_graphics.html 的 樣板。如果圖片是衍生作品，請提供指向其衍生圖片的連結（或至少是參考）。
  7. 選擇一個或多個關鍵字，這些關鍵字將用於在主選單中選擇新頁面。目前我們有以下關鍵字（檢查選擇表單以了解每個關鍵字涵蓋的內容）

    主題： gnuhead、gnu、tux、rms、emacs、fs、license、drm、surveillance。
    類型： ai、ascii、banner、button、icon、cartoon、plastic、logo、poster、svg、wallpaper。

    請隨時根據需要新增更多關鍵字，但如果您這樣做，請不要忘記更新選擇表單。
  8. 在主選單中為新頁面新增條目。最方便的方法是複製其中一個條目，並將關鍵字、連結、頁面標題和作者替換為新頁面的。以下是 arantxa.html 條目的外觀
        <!--#if expr="$THEME = /^(gnuhead|)$/
               && $TYPE  = /^(banner|logo|)$/" -->
 <tr><td><a href="/graphics/arantxa.html">
     <img src="/graphics/icons/arantxa-glitch.80.png"
           alt="&nbsp;[Glitch]&nbsp;" /></a></td>
     <td>GNU designs<br />
     <small>by Arantxa Serantes</small></td></tr><!--#endif
 -->
    請注意，條目以 SSI 指令開始和結束，並且在 endif 內而不是在其後有一個換行符，以避免在提供給使用者的 HTML 中出現大量空白行。

更新 GNU 套件列表中的資訊

有時，GNU 套件的維護者會請求更新其在 GNU 套件列表中的條目

這些檔案的來源維護在 /prep/gnumaint/ 中。

  1. 下載 htmlxref.cnf

     torsocks wget \
   -O htmlxref.cnf \
   https://ftpmirror.gnu.org/texinfo/htmlxref.cnf
  2. 編輯 rec/gnupackages.rec、rec/oldpackages.rec 和 rec/pkgblurbs.rec。

  3. 重新產生檔案。您可能想將 ./ 新增到您的 PATH

     make gnupackages.txt html-update PATH=".:$PATH"

  4. 確保差異看起來符合預期

     cvs diff ../../{graphics,manual,software}/allgnupkgs.html \
     ../../software/oldgnupkgs.html \
     ../../server/home-pkgblurbs.html | less
  5. 返回 gnumaint 並將您的變更提交到來源檔案，然後將更新提交到 www 儲存庫。如果需要對 htmlxref.cnf 進行任何變更，請將其發送至 bug-texinfo 郵寄列表。

Planet GNU

Planet GNU 上的訂閱源通常應遵循我們的連結政策。

對 Planet GNU 進行變更，例如新增或移除訂閱源，是透過在適當的 git 儲存庫中進行變更來完成的

變更不會立即生效，而是在 cron 工作執行後生效，該工作於每小時的第 25 分鐘開始。

更多資訊可以在 Savannah 的使用 Git 頁面上找到。

日誌訊息

撰寫良好的提交日誌訊息非常重要，有助於專案成員和後代找到給定檔案中的特定變更，並理解您的變更原因。

  • 在不過於冗長的情況下，日誌訊息應盡可能清楚地描述提交的性質。
    良好範例：更新 XYZ 的連結。
    不良範例：更新連結。
  • 務必包含對任何相關 RT 工單和/或郵寄列表討論的參考。如果不存在此類參考，請提及授權變更的人員姓名。
  • 對於日期，我們使用美式表示法（Sept. 27, 2023）或 ISO 8601 國際標準格式（2023-09-27）。