華夏公益教科書:政策和指南/投票/命名政策

華夏公益教科書：命名政策

簡介

目前華夏公益教科書沒有官方的命名政策。我們不能對新書實施任何命名約定，也沒有明確的指南指導新使用者如何命名頁面。本提案旨在引入一套最少且簡單的規則。它不涵蓋所有情況——例如模板、類別、書籍名稱快捷方式等的命名將在以後討論（如果有必要），請不要將它們與本提案聯絡起來。

提議

• 新書 - 僅允許斜槓作為頁面名稱的分隔符。頁面名稱必須採用 <書籍名稱/章節名稱> 的格式。冒號作為分隔符僅保留給 Cookbook 使用。
• 現有書籍 - 可以使用任何約定，前提是書籍名稱包含在每個章節標題中。因此，我們不再允許使用諸如 Contents 之類的通用名稱的章節，這些章節沒有在標題中包含書籍名稱。任何現有書籍都不會使用有關頁面命名的清理框。現有書籍必須在其所有頁面上提供自己的反向連結（斜槓約定除外，它會自動提供反向連結）。
• 執行 - 可以對不符合要求的新書的討論頁面（而不是模組頁面）提出禮貌的清理請求。對現有書籍沒有執行措施。

理由

優勢

• 在現有書籍中廣泛傳播，並且在大多數新書中使用
• 一致、清晰、易於讀者和編輯理解的命名政策
• 斜槓約定提供預格式化的自動反向連結到上級頁面（書籍名稱、章節名稱）
• 斜槓約定提供使用快速連結到子章節（[[/chapter/]]）和同級章節（[[../sibling/]]）的獨家可能性，節省了輸入較長形式（[[bookname/chapter]])
• 冒號約定：僅適用於名稱空間（Cookbook 是其中之一）
• 消除現狀，即
  • 兩本完全不同的書籍可能在不知情的情況下連結到同一章節（例如 Contents）
  • 自動化任務（使用機器人修復錯誤）很困難
  • 這可能會讓讀者和貢獻者感到困惑（如果貢獻者看到兩本書採用完全不同的命名約定）
  • 允許在一本書中使用兩種不同的命名約定

劣勢

• 不允許書籍作者決定哪種命名約定最適合他們
• 強制書籍章節名稱看起來像計算機檔名，例如：Windmills/Australian farms
• 如果作者想要使用更好的書籍章節標題，例如“History of Windmills on Australian Farms”，那麼該頁面將出現兩個大字號標題
• 斜槓約定在每個頁面上插入一個強制性的（無法關閉）第二行文字，其中包含預格式化的反向連結，如果頁面包含自己的反向連結或書籍內容模板（例如 Botany 示例），則該行文字是不必要的。

投票

只有註冊使用者且編輯次數不少於 20 次的使用者才能投票。投票於 3 月 1 日格林威治標準時間 00:01 結束，結果是該動議以 14 比 2 的優勢透過。

贊成

1. 贊成 Krischik ^T 2006 年 2 月 12 日 17:42 (UTC)
2. 贊成 此外，應該鼓勵現有書籍（儘管目前沒有強制要求）採用新書強制採用的格式， Jguk 2006 年 2 月 13 日 15:40 (UTC)
3. 贊成 雖然我也希望看到冒號約定作為新書的一個選項。我們目前需要某種政策，關於是否允許冒號的辯論可以作為獨立的問題和投票進行。--Rob Horning 2006 年 2 月 13 日 16:17 (UTC)
4. 贊成 - 對我來說可以。 -Matt 2006 年 2 月 13 日 18:00 (UTC)
5. 贊成 - 我們需要一致性，這是一個開始，但應該擴充套件到所有書籍。 Gerard Foley 2006 年 2 月 13 日 22:09 (UTC)
6. 贊成 我也在下面的討論部分添加了一條評論 (現有書籍)。--JMRyan 2006 年 2 月 13 日 22:57 (UTC)
7. 贊成 儘管我也希望將來將其擴充套件到所有書籍。一致性很重要。 ManuelGR 2006 年 2 月 14 日 22:48 (UTC)
8. 贊成 --Kernigh 2006 年 2 月 15 日 00:27 (UTC)
9. 贊成 作為這項政策的主要支持者之一，我當然贊成它；-) Derbeth ^talk 2006 年 2 月 15 日 09:23 (UTC)
10. 一致性與準確性同等重要。--LV ^{(黑暗標記)} 2006年2月17日 (UTC) 02:45
11. 是的但請參閱下面的說明。 --kwhitefoot 2006年2月17日 (UTC) 11:22
12. 是的對於現有的書籍，我們可能需要考慮更改它們，但保留重定向以供連結使用 --Gabe Sechan 2006年2月17日 (UTC) 22:27
13. 是的 The Doc正如我們在 it:wb 中所做的那樣，所有書籍頁面都應重新命名 2006年2月19日 (UTC) 12:01
14. 是的 不過，我很好奇，例如，"程式設計" 名稱空間是否可行... (?) - marsian 2006年2月21日 (UTC) 04:45
    

投票現已結束

不

1. 不- 投票“不”意味著作者可以選擇使用斜槓約定、冒號約定或其他可接受的約定。 KHatcher 2006年2月21日 (UTC) 16:36
2. 不- 我不同意強制使用具有明顯劣勢的命名約定（參見下面的 討論）。作者在建立維基百科時必須有選擇權。 BDB 2006年2月24日 (UTC) 18:37
   

投票現已結束

討論

在 維基百科討論：命名策略 中進行了非常長時間的討論。

冒號

我注意到 Rob Horning 的投票以及他表示希望對新書使用冒號約定，但可以稍後討論。我認為這次投票在關於新書使用冒號約定的立場方面相當堅定，即不允許使用冒號約定。就這樣。我個人希望冒號約定透過這次投票成為最終的否決。其他人是否認為這個問題還有商榷的餘地，因為在我看來，經過所有討論後，這個問題應該已經明確了？ -Matt 2006年2月13日 (UTC) 18:05

任何人都可以在該策略被採納後（假設它會被採納）提出他們想要的任何修改。但是，這樣的修改是否會被接受則是另一回事，這將取決於是否達成共識， Jguk 2006年2月13日 (UTC) 18:29

你完全說對了，Jguk。我希望無論如何都能實施某種命名策略，無論之後會發生什麼。我和 Matt 可以就使用冒號約定進行單獨爭論，我想我們在這方面持有不同的觀點。我們不應該讓多數人的暴政將概念和問題強加於所有人，僅僅因為我認為需要制定某種策略，並不意味著我同意整個策略。這個策略最終會在未來某個時候進行修訂，而且應該如此。新的使用者將加入維基百科，而老使用者（可能包括我）將離開。這類策略不應該被“固定”而沒有被審查的可能性，以確保其在日後仍然相關。目前，幾乎所有東西都可以使用斜槓、冒號、插入符、星號、金橘、括號、迷地原力或沒有命名約定，在我看來，這是不可接受的，需要改變。--Rob Horning 2006年2月19日 (UTC) 13:00

現有書籍

我上面投票了“是”。但是，我對現有書籍的措辭感到不舒服。我更希望斜槓策略適用於所有書籍，但對滿足既定最低要求的現有書籍不予執行。這樣，我們至少開始了逐步淘汰或廢除非斜槓命名的過程。我理解並樂於支援將現有書籍問題作為稍後解決的問題：我們需要從某個地方開始做出決定。但即使如此，我還是希望這個策略聽起來更像是將現有書籍問題作為稍後解決的問題，而不是像一個決定來將現有書籍的名稱列入祖先條款一樣。--JMRyan 2006年2月13日 (UTC) 23:15

討論頁面

我已開始使用討論頁來標記違規 - 如本投票所建議。 我覺得這行不通。 NC 違規通常由不習慣檢查討論頁的新使用者造成。 當然，我仍然贊成，因為我相信這種極簡主義方法是一個非常好的開始，如果有些事情沒有按預期進行，我們以後可以更容易地解決。 --Krischik ^T 2006 年 2 月 15 日 11:51 (UTC)

如果您想聯絡新使用者，使用者討論頁也是一個好去處。 那個橙色的橫幅（“您有新訊息”）通常足以讓新使用者注意到。 --Rob Horning 2006 年 2 月 19 日 13:24 (UTC)

但這隻有在使用者實際註冊的情況下才有效。 這是一個將頂級建立限制為僅註冊使用者的論據。 --Krischik ^T 2006 年 2 月 25 日 06:52 (UTC)

因模糊而剝奪權利

我認為整個問題都在以一種幾乎不可能讓那些不精通計算機的人理解的方式進行討論，這意味著只有那些人會投票。 此外，由於提議的結構符合大多數這類人每天處理的內容，因此異議意見似乎很少見，不是因為其他可能性沒有價值，而是因為被認為有能力討論這個問題的人群是從一個可能傾向於投票支援特定備選方案的人群中挑選出來的。 事實上，許多術語對我來說似乎都很模糊，而我擁有三十多年的計算機經驗。 是否有一頁真正清楚地定義了“名稱空間”、“標題”、“書架”、“書名”等術語？ 我貢獻最多的那本書的標題是“Visual Basic Classic”，但我懷疑“書名”是指“Programming:Visual Basic Classic”。 如果我用斜槓替換冒號，那麼“書名”是什麼？ 也許我們需要採取更嚴格的計算方法，定義一個正式的語法。 模糊地談論“計算機檔名”是不夠的，並非所有檔案系統都使用分層結構，許多使用此類系統的人在使用分層結構時也不理解它們。 我希望其中一些內容有意義。 --kwhitefoot 2006 年 2 月 17 日 11:48 (UTC)

我理解該提案的含義是，所有在“書名”這本書中的頁面都必須以“書名/”開頭。 之後，各個書籍可以自由地使用任何對該書籍最合適的、合理的方案。 我不同意您所說的您的書名應該是“Programming:Visual Basic Classic”。 它仍然是“Visual Basic Classic” - 它會放在“Programming”或“Computer Programming”書架上，Jguk 2006 年 2 月 17 日 12:17 (UTC)

如果我沒記錯，之前有一些關於“Programming:Foobar”書籍命名的討論。 我當時沒有太關注，因為我沒有參與那些書籍的編輯工作。 我認為（其他人可能比你更準確）這至少在一定程度上已得到解決，贊成將“Programming:Foobar”書籍重新命名為“Foobar”或“Foobar Programming”之類的名稱。 Programming:Ada 和 Programing:C# 被移到了 Ada Programming 和 C# Programming，而 Programming:Prolog 和 Programming:Visual Basic .NET 被移到了 Prolog 和 Visual Basic .NET。 此外，Programming 本身被移到了 Computer programming。 如果你能跟上，那麼你就應該將 Programming:Visual Basic Classic 移動到“Visual Basic Classic”或（不太可能）“Visual Basic Classic Programming”，甚至“Programming in Visual Basic Classic”。 雖然 Programming:Visual Basic Classic 中的冒號最初是為了作為分隔符而設計的，但它不再能很好地發揮分隔符的作用，因為不再存在“Programming”書籍。 這確實不幸地使您的標題的狀況有些模糊。 (1) 也許您的書籍最好被視為現已不存在（除了作為重定向）的“Programming”書籍中的子書籍——這是一個不幸的狀況。 在這種情況下，您的書名是“Programming”。 (2) 如果您用斜槓替換冒號，那麼您的書名明確地是“Programming”，您的書籍明確地是現已不存在的“Programming”的子書籍——同樣是一個不幸的狀況。 (3) 也許您書籍中的冒號應該被解釋為一個普通的冒號（如 Harbison 和 Steele 的“C: A Reference Manual”）。 那麼您的書名是“Programming:Visual Basic Classic”。 在這種情況下，您的書籍至少在一定程度上遵循了斜槓約定，因為有像 Programming:Visual Basic Classic/Strings 這樣的頁面。 我猜想，冒號後面沒有空格使得 (1) 成為最有可能的解釋。 無論如何，您的書籍都位於 程式語言書架 上，因為該書架上有指向您書籍的連結。 我的建議——免費，而且物超所值——是最好將書籍改名為“Visual Basic Classic”或“Programming in Visual Basic Classic”。 如果有多個活躍的作者，則需要在他們之間達成共識。 如果你願意，有一個機器人，tsca.bot，可以幫助你完成繁瑣的工作。 它需要幫助才能提供幫助，我不知道如何提出這樣的請求。 我希望這能改善模糊不清的問題，並使一切都變得清晰。 :-) --JMRyan 2006 年 2 月 17 日 20:38 (UTC)

命名策略或命名指南

我認為，命名規範很快就會成為一項強制政策。維基百科和華夏公益教科書除了是資訊來源外，也代表著自由——自由地以你想要的方式撰寫文章或書籍。這種自由強調了我們生活中多樣性的美。我相信大多數華夏公益教科書作者已經忘記了維基百科第五條也是最重要的一條原則是什麼（請參見 維基百科五條原則）。制定更多規則並強制執行它們將使華夏公益教科書更加統一，但會對新來者和現有作者施加更多限制。這是我對強制執行命名規範的基本反對意見。其次，使用斜槓作為頁面名稱分隔符的擬議政策有一些缺點，支持者忽略了這些缺點。在醫學等學科中，主題可能出現在多個章節下，因為疾病或人體不像人造軟體或任何其他事物那樣相互重疊，可能無法明確區分。從技術上講，醫學通常處理連續變數，不像工程或計算機科學的學生處理的離散變數。例如，像 反射性交感神經失養症 這樣的主題可能出現在 手外科和顯微外科、兒科外科 和 運動醫學 等章節中。冒號約定使得在各種章節中列出主題變得容易，而無需重複！冒號有助於識別和連結它所屬的書籍。這樣就不會有書籍之間的內部連結。我寧願將書籍看作是關於某個主題的文章集合，而不是嚴格命名的章節的教條式集合，這些章節符合強制執行的政策。第三，自動連結回不是遵循斜槓約定的理由。作者已經建立了更簡潔、更具吸引力的導航模板（參見 植物學），沒有理由透過提供自動連結來抑制這種創造力。第四，最不重要的原因是，斜槓約定會使每個頁面的標題變長，如果層次結構很深，我不得不說，很醜陋。冒號會使每個頁面的標題保持簡短、簡潔和整齊。我承認，有些書籍使用斜槓可能是一個更好的選擇，因此我支援允許作者自行決定什麼更適合他們的書籍。--BDB 2006年2月24日 (星期五) 19:47 (UTC)

擬議的政策實際上只要求書中所有頁面都以 書名/ 開頭。在此之後，頁面組織完全由各個作者決定。關於你與維基百科的比較，我注意到這是一個單獨的專案，我們應該有權利，也應該有權利，在適當情況下制定單獨的規則。 Jguk 2006年2月25日 (星期六) 07:38 (UTC)

我不確定當前擬議的政策是否一定與該理念相符。 食譜就是一個例子，說明了某個事物是如何從偽名稱空間發展成為該專案中的完整名稱空間的，冒號是其中關鍵的一部分。我不知道完整名稱空間對於食譜作為維基專案是否至關重要，但它確實為該書籍賦予了一種獨特的風格。如果食譜被免除，那麼其他書籍專案遲早也會開始呼籲享有相同的“平等待遇”，我無法理解食譜有什麼特殊之處，除了它是一個管理員的寵兒專案（這在華夏公益教科書上不一定是問題），他們找到了一些開發者將其變成一個名稱空間。

我強烈建議作者保持個性，冒號本身就是一個合乎邏輯的分隔符，這使得它看起來像一個合理的替代方案。我傾向於認為，只有在有人嚴重濫用情況，並且你想要確保將來如果有人試圖做同樣的事情傷害他人，你能夠有效地懲罰那些白痴時，才應該制定政策、規則或法律。關於某種命名規範的規則是有效的，因為將模組命名為任何事物（比如假裝這是維基百科，你可以有像 目錄、索引 或 附錄 這樣的章節）根本沒有意義，並且嘗試重新連結那些這樣命名的孤立內容很麻煩。孤立模組在華夏公益教科書中是一個非常嚴重的問題，未來會更嚴重。至於除了在模組標題中某個地方有書籍名稱（為了搜尋目的，最好放在開頭）之外的特定風格，我準備為此而戰，並允許其他標準。--Rob Horning 2006年2月25日 (星期六) 08:03 (UTC)

"維基百科和華夏公益教科書除了是資訊來源外，也代表著自由——自由地以你想要的方式撰寫文章或書籍"——不，這不是自由，而是無政府狀態。在維基百科中，你不能隨意撰寫文章——人物傳記、國家等文章都有標準。我認為，對於書籍作者來說，擁有自由選擇頁面名稱並不重要。正如我之前所說，書籍作者應該撰寫書籍，而不是試圖發明新的命名方案。命名方案是完全無關緊要的事情，大多數讀者不會去看頁面的實際名稱，他們閱讀的是內容。"制定更多規則並強制執行它們將使華夏公益教科書更加統一，但會對新來者和現有作者施加更多限制。"如果我是想做出貢獻的新人，當我發現許多書籍使用完全不同的頁面命名方式時，我會非常困惑。如果一本書使用兩種不同的風格怎麼辦？"第四，最不重要的原因是，斜槓約定會使每個頁面的標題變長，如果層次結構很深，我不得不說，很醜陋。"這表明你不理解提議的內容。你可以建立任意深度的書籍層次結構，並讓頁面名稱僅包含兩個部分：書籍名稱和章節名稱。斜槓約定不是關於在頁面名稱中顯示書籍內部結構，而是關於在頁面名稱中顯示書籍名稱，僅此而已。"我寧願將書籍看作是關於某個主題的文章集合，而不是嚴格命名的章節的教條式集合，這些章節符合強制執行的政策。"書籍不是鬆散的文章集合。嘗試列印然後閱讀這樣的“書籍”。 意識研究就是一個結構良好的華夏公益教科書的例子。--Derbeth ^討論 2006年2月25日 (星期六) 11:55 (UTC)

Jguk，雖然你提到它只強制改變標題/子頁面名稱，但你在 骨科手術 中所做的更改擴充套件到了標題/子頁面名稱1/子頁面名稱2，如 骨科手術/基礎科學/骨骼損傷與修復。我們實施該政策是因為我們想要或需要與維基百科不同嗎？華夏公益教科書是一個不同的專案，但並不一定會有一套單獨的規則。我試圖提出的觀點是，我們是否需要命名 指南 而不是僵化的 政策。

Derbeth，我很快就會回來回答你提出的問題。 BDB 2006年2月25日 (星期六) 17:07 (UTC)

我很樂意看到你在骨科手術頁面上實現的任何其他結構，只要這本書中的每個頁面都以“骨科手術/”開頭。我試圖保留這本書現有的結構，同時對其進行重新命名。不幸的是，我很快就發現我不確定現有的結構是什麼（似乎存在兩種相互競爭的結構，但如果我錯了，我道歉）。這就是我停止進行大量其他更改的原因。如果你能告訴我你認為這本書應該採用的結構，我很樂意幫助你實現它。關於維基百科的問題，我們與維基百科不同 - 這意味著我們不一定與維基百科具有相同的規則和結構，而不是我們故意制定不同的規則和結構 - 我們應該做任何對華夏公益教科書合適的事情， Jguk 2006年2月25日 (星期六) 18:01 (UTC)

我仍然不清楚這一點。我更喜歡的結構是骨科手術：而不是骨科手術/。為什麼在它仍然是提議的情況下強制執行這條規則？命名策略仍然列在提議下，而不是列在強制執行列中，我們不是在投票中進行討論嗎？但可能是因為我們中有些人不想讓像食譜這樣的名稱空間存在，我們更喜歡標題/結構而不是標題：。我還沒有決定什麼是最好的，這就是我在這裡的原因。可能，標題/章節名稱：將滿足目的。我還發現使用斜槓結構進行管道操作很困難，而使用冒號則更簡單。我認為，使用斜槓約定在華夏公益教科書中搜索主題會非常不方便。我很想聽聽你對此的意見。回到維基百科，我想補充你所說的話：“我們應該做任何對華夏公益教科書合適的事情” - 無論它是否來自維基百科。 -BDB 2006年2月25日 (星期六) 18:24 (UTC)

說實話，我最初看到並更改的頁面格式是頁面標題（骨科手術），如果我看到所有頁面都完全一致地使用骨科手術：頁面標題，我就會把它留著不動。無論如何，我相信我們都同意應該保持一致，最好是書名放在前面， Jguk 2006年2月25日 (星期六) 21:03 (UTC)

是的，我當時對這本書的結構非常不確定，而且有些頁面命名為子頁面名稱1（標題）。我完全同意你的觀點，書名應該放在前面，然後是章節名稱或子頁面名稱。 -BDB 2006年2月26日 (星期日) 06:55 (UTC)

Derbeth，自由伴隨著責任，當我們不再負責任時，就會出現混亂。我認為華夏公益教科書作者遠沒有不負責任。不要將華夏公益教科書中看似混亂的活動誤認為是混亂。混亂中總是有規律，只是需要一段時間才能變得清晰。我曾經，現在仍然認為，我們對作者強加的規則越少，華夏公益教科書就會變得越美觀。讓我們制定指南，但不要執行強制性策略。維基百科標準經過一段時間才發展起來。它們不是一夜之間實施的。作者應該擁有與書內容一樣多的對書結構的權利。是否每個人都感興趣並不重要。一本圖書應該採用什麼命名約定，理想情況下應該由其作者決定，而不是由你、我或任何管理員決定。我真誠地不明白這句話：“你可以擁有任意深的圖書層次結構，並且頁面的名稱只包含兩個部分：圖書名稱和章節名稱。斜槓約定不是為了在頁面名稱中顯示內部圖書結構，而是為了在頁面名稱中顯示圖書名稱，僅此而已。”。你能更清楚地解釋一下嗎？最後，雖然華夏公益教科書的目標是看起來像一本印刷書籍，但我認為它與印刷材料有很大區別。 -BDB 2006年2月25日 (星期六) 18:47 (UTC)

好的。讓我們以一本虛構的醫學書為例。你想寫一個關於“胸腺”的章節。你不應該像這樣命名頁面：“醫學/免疫學/免疫系統器官/胸腺”，儘管這是你書中該章節在層次結構中的位置。你只需要把它命名為“醫學/胸腺”。它真的很長嗎？你寫道：“作者應該擁有與書內容一樣多的對書結構的權利。”但華夏公益教科書已經存在了近三年，作者們有足夠的時間去嘗試和觀察不同的命名約定是如何工作的。現在斜槓約定是最受歡迎的，我認為沒有理由允許更多沒有這種約定優點的命名約定。自由很重要，但你為什麼需要在選擇書中使用的分隔符時擁有自由？冒號和斜槓之間的選擇對你很重要嗎？我不接受只是為了自由而存在的自由，我們不是在這裡給任何人自由去做他想做的事情，我們是在這裡寫好書。維基百科不是民主，華夏公益教科書也不是。在維基百科中，你不能將頁面命名為“眼鏡蛇 - 蛇”或“眼鏡蛇，蛇”，這樣的頁面將立即被重新命名，甚至不會問你，沒有人說維基百科不自由。 --Derbeth ^討論 2006年2月26日 (星期一) 15:36 (UTC)

Derbeth，我被迫遵循你提出的頁面命名結構。 Medicine/Thymus 太棒了！ 但我完全不同意你的自由概念。 雖然你提到 - “維基百科不是民主”，並且這是官方政策（見 維基百科不是民主），但我請求你進一步閱讀並檢視 維基百科不是官僚機構，我引用 - “分歧應透過共識討論解決，而不是嚴格遵循規則和程式。 應該避免 指令蔓延。 遵循任何規則、政策和指南的精神，而不是文字”。 我陳述我的觀點！ -BDB 2006 年 2 月 26 日 18:42 (UTC)

但我們正在討論。 你舉了個非常錯誤的例子。 是的，我們不應該制定大量的指南和政策，但總有一些規則必須遵守以保持專案的秩序。 想想維基百科上的消歧頁面命名約定 - 你可以忽略它嗎？ 不行，因為它至關重要。 我認為命名政策是這種基本規則； 基礎是因為這裡實際上沒有多少政策，我們也沒有要求太多。 只要按我們要求的方式命名頁面，一切就都好了 - 這就是我們所說的。 建議的命名約定非常簡單，簡而言之： “在你的書中建立的每個頁面的名稱中新增書名斜槓”。 考慮一下 - 我們給予圖書作者巨大的自由空間，命名政策並沒有阻止他們按照自己的意願組織圖書。 在我看來，頁面名稱不是創意工作的一部分，就像電腦上的檔名一樣 - 命名方式並不重要，重要的是內容。 想象一下，作業系統只允許你以大寫字母開標頭檔案名。 這是一種限制，但這對檔名首字母是什麼有實際意義嗎？ 如果我編輯或列印它，它就完全無關緊要了。 --Derbeth ^討論 2006 年 2 月 26 日 22:06 (UTC)