Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
Advertisement

社群專頁是為使用者討論編輯相關話題設立的。使用者也可以在對應頁面、使用者的討論頁討論。在發言後請記得加入~~~~簽名。

請了解,Minecraft Wiki在共識系統上運作而不是投票決定,清楚地闡述自己的理由比簡單地支持爭論的一方更有效。

涉及管理員權限的相關事宜請發佈於管理員告示板。涉及繁簡字詞轉換等問題請到繁體中文問題報告中提出。

常用頁面

Minecraft Wiki不是客戶服務中心!遊戲問題請移步Minecraft說明中心或者玩家遊戲社群。

所有在該頁面上發表的無關話題都將被存檔至無意義話題處。

請點擊下面的「發起議題」按鈕或頁面上面的「加入話題」標籤在頁面底部發表新的議題。
如果您在頁面上發現有簡繁轉換錯誤或繁體中文譯名沒有正確顯示,請在這裡提出,我們將會儘快修復。


語言

最新Wiki新聞
  • 2023年8月31日 - 中文Minecraft Wiki確定將遷移至Weird Gloop(議題原文)。
  • 2023年7月4日 - 英文Minecraft Wiki公開發布了關於Minecraft Wiki是否要從Fandom遷移至別的站點的討論(連結)。
  • 2023年6月1日 - 新的巡查員Siiftun1857上任。
  • 2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升級至1.39。
  • 2023年1月31日 - 新的管理員Anterdc99上任。
# 話題 發言條數 參與人數 發起者 最後發言者 最後發言時間(UTC)
1 製作了總討論頁的頂端目錄 6 2 star00 star00 2021年4月6日 (二) 14:42
2 重新規劃生物分類 7 5 siiftun1857 Endearing Cat 2021年4月15日 (四) 13:55
3 提議修改格式指導,以及再次更新Message box樣式 18 7 MysticNebula70 MysticNebula70 2021年5月4日 (二) 13:28
4 是否應加入有關盔甲和工具的重新導向 4 3 AblazeVase69188 AblazeVase69188 2021年4月30日 (五) 15:15
5 深層綠寶石(銅、煤)礦石的相關解釋需要改嗎? 2 2 Minesunset1030 Lxazl5770 2021年5月5日 (三) 15:56
6 重寫LootChest模組 8 6 Star00 RealCuervo 2021年5月4日 (二) 16:36
7 修改Minecraft Wiki:管理制度 14 7 Dianliang233 Powup333 2021年5月7日 (五) 05:16
話題

製作了總討論頁的頂端目錄

本人製作了用於總討論頁的頂端目錄,可以方便的查看目前存在的論題及相關資訊,具有多種的標記功能(功能一看就懂就不贅述了),效果如下。

如覺得不錯可考慮應用於Minecraft Wiki:社群專頁Minecraft Wiki:管理員告示板的header中。--Star Zero · 維基假期中 2021年4月3日 (六) 07:13 (UTC)

 問題:就目前來看此模組仍存在較多影響正常使用的問題,因此暫持保留意見。MysticNebula70 T  2021年4月3日 (六) 07:53 (UTC)
問題已全部解決。--Star Zero · 維基假期中 2021年4月4日 (日) 04:05 (UTC)
根據你的成果重寫了模組,如測試無問題且無異議即可將其轉正。MysticNebula70 T  2021年4月4日 (日) 13:36 (UTC)
感謝貓貓的協助。--Star Zero · 維基假期中 2021年4月6日 (二) 14:42 (UTC)
另此模板還需要修改討論透過論題後的顏色,原透過模板背景顏色與24小時內更新顏色不易區分。--Star Zero · 維基假期中 2021年4月6日 (二) 14:42 (UTC)

重新規劃生物分類

由於生物分類異常混亂且缺乏規則,我一點時間整理了這些內容。然而,介於這是一個不小的變動,對先前分類方式的完全顛覆,我希望在大動干戈之前能夠先取得社群共識。

草稿已經提交至沙盒,包含對生物條目和{{Entities/content}}的變更。

這個變更的主要內容是將生物分類由被動型/中立型/敵對型這三大類改為友好生物/敵對生物這兩類,拋棄中立型類別並將其中的生物送入前兩個大類的子分類。

如果達成共識,那麼所有生物條目的infobox內的生物類型也會更新,並且在這一方向將不再與En看齊。--Magnussiiftun1857[T/C/E] 2021年4月5日 (一) 07:29 (UTC)(最後編輯於2021年4月5日 (一) 13:24 (UTC))

 支持對生物分類進行變更 較反對全部改變到新分類方式。先不論文章實際內容(因為反正總得有個標準),拋棄中立型合併到其他類別的變更會給讀者造成直覺阻礙。雖然很多頁面都要說「中立型和敵對型」,然後再去除中立型裏面的動物,確實造成了表意贅餘,但是除了這種贅餘之外,是否還有更多需要改動的必要?
此外,兩個分類方式是否有原始碼層面的依據?目前的提案應該是來源自聲音事件分類,但是這似乎不能說「就和原始碼層面對Mob的處理」完全一致。如果有人能基於某一套反混淆(我建議yarn或者Mojmap)給出相應的依據,我覺得會更清晰一些。-- LakeJasonFace Lakejason0) 2021年4月5日 (一) 07:41 (UTC)
 問題:友好生物/敵對生物如何判定?這只能主觀判定吧。-- Dianliang233 TC 16 2021年4月5日 (一) 08:33 (UTC)
per myself,根據sounds.json內的聲音事件類別。-- LakeJasonFace Lakejason0) 2021年4月5日 (一) 08:37 (UTC)
標準的選擇其實相當多……不過我傾向於,將是否被進度「怪物獵人」和「資深怪物獵人」追蹤,視為目前的決定性標準。
實際上,友好生物和敵對生物分類的內容來自先前的被動型和攻擊型,區別只有多了原本歸類於中立型的生物。--Magnussiiftun1857[T/C/E] 2021年4月8日 (四) 18:05 (UTC)
關於區分友好生物和敵對生物,遊戲裏本身也分不清楚(比如可以蜇人的蜜蜂屬於友好生物,豬布林屬於敵對生物,北極熊在Java版算友好生物在基岩版卻算敵對生物),所以我個人還是贊成保留現有的區分方法。--Lxazl5770zh.admin) 2021年4月13日 (二) 02:51 (UTC)

 現有分類方式確需改進 不建議這樣變更。很多讀者可能已經習慣了現有的分類方式,這樣變更會使一些人難以接受。我認為基於現有的分類方式上進行合理的變更會更好。--Endearing Cat討論) 2021年4月15日 (四) 13:55 (UTC)

提議修改格式指導,以及再次更新Message box樣式

下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 同意更新


目前中文wiki的msgbox是放在infobox之後的,這並不符合大多數wiki的主流佈局。我建議按照多數wiki的做法來,先msgbox然後infobox,並修改格式指導。

然後,目前的msgbox樣式不能適應以上的調整,需要相應修改。大致需要變更的內容有:

  1. 將所有非mini的msgbox統一寬度;
  2. 增加msgbox的外邊框;
  3. 兩個相鄰的msgbox取消間隔;
  4. msgbox內的文字改為左對齊。

另外,msgbox可以使用預設的顏色(目前有7個:red、​orange、​yellow、​green、​blue、​purplemagenta),以不同的顏色表示不同類型的資訊(如紅色表示需要立即執行的操作,橙色表示頁面有內容方面的問題,等等),同時仍然支持自訂顏色。

此處可以預覽新樣式。

現在此徵詢社群的意見。MysticNebula70 T  2021年4月16日 (五) 12:24 (UTC)

 支持。不過和英文的差別還是很大,和正經Ambox的差距倒是很小。-- LakeJasonFace Lakejason0) 2021年4月16日 (五) 14:07 (UTC)
大部分 支持。只不過那個灰色的border我不大喜歡。-- Dianliang233 TC 16 2021年4月16日 (五) 14:11 (UTC)
需要修改的還有消歧義模板。正常的順序為消歧義-訊息框(msgbox)-資訊框(infobox)。
對於預設顏色,我建議使用type(模式),每個模式對應一種顏色,然後選擇模式。以及我個人建議不同名字空間設定不同樣式。
對於文字左對齊,我認為現在mcw的訊息框寬度太小了,居左可能不太好看,如果要居左最好寬度拉長點,視具體情況而定。--Star Zero · 維基假期中 2021年4月16日 (五) 14:12 (UTC)
 支持,預覽看著不錯。不過調換很多頁面的順序確實是個很麻煩的工作。。--Snow dash & ) 2021年4月16日 (五) 14:14 (UTC)
 同意,新樣式挺好看--Lxazl5770zh.admin) 2021年4月16日 (五) 15:35 (UTC)

目前有部分成員提出不加入灰色邊框。對此條建議有其他看法的請在此回復。MysticNebula70 T  2021年4月17日 (六) 11:33 (UTC)

移除了灰邊框,效果請自行對比。MysticNebula70 T  2021年4月20日 (二) 10:28 (UTC)

預設顏色的用途

各個預設顏色的使用場合是什麼?有關想法請在此提出。對配色本身有意見也在此提出。MysticNebula70 T  2021年4月17日 (六) 02:26 (UTC)

忽然才意識到這些配色在我的顯示器上很素,很暗。如果改的更亮一點呢?-- LakeJasonFace Lakejason0) 2021年4月17日 (六) 03:40 (UTC)

目前英文wiki選取的顏色用途:

  • red:disclaimer和提刪;
  • purple:建議頁面移動、拆分、合併;
  • orange:頁面存在內容問題;
  • yellow:頁面存在格式問題;
  • green:標記頁面的其他狀態(例如是stub、正在編寫中);
  • blue:標記版本相關(例如版本獨有、將在下個版本加入);
  • magenta:未使用/自訂。

以上內容可供參考。

另:若按照type來選取顏色,則仍然需要確定一些預設的type用來對應顏色。如果同意使用type,可在此提議type。MysticNebula70 T  2021年4月17日 (六) 11:43 (UTC)(最後編輯於2021年4月17日 (六) 12:31 (UTC))

 建議:新增顏色gray,用於表示丟失(如{{Lost version}}{{Lost pre-reupload}})、未發佈(如{{Unreleased}})或者可能不存在(如{{Unproven}})的版本。--Ultim 0 ( VIEW | TALK | CONT ) 2021年4月17日 (六) 12:21 (UTC)(最後編輯於2021年4月17日 (六) 12:39 (UTC))
這樣的type咋樣:
  • red->important
  • purple->pageaction
  • orange->problem
  • yellow->notice
  • green->pagestatus
  • blue->version
-- LakeJasonFace Lakejason0) 2021年4月17日 (六) 12:44 (UTC)(最後編輯於2021年4月17日 (六) 12:45 (UTC))
 不認可:都不怎麼樣,行為和程度混雜,單詞和雙詞混雜,而且和用途不搭,建議全部重定。--Star Zero · 維基假期中 2021年4月19日 (一) 01:40 (UTC)
建議方案:
類型(顏色) \ 名字空間 條目名字空間 檔案名字空間 討論名字空間
delete(red) 請求刪除
move(purple) 移動、拆分和合併 移動和重新命名 合併,拆分和重新命名
content(orange) 內容問題 嚴重警告和問題 大部分警告和提醒
style(yellow) 格式問題 較輕警告和問題 較小警告和提醒
protection(grey) 保護
version(blue) 版本 \ \
notice(default) 條目注意 注意 通知和訊息
Star Zero · 維基假期中 2021年5月4日 (二) 10:43 (UTC)
建議補充green,用於標示正在進行的工作以及未完成的頁面。--Ultim_0 ( USER | TALK | CONT ) 2021年5月4日 (二) 10:54 (UTC)
修改版本:
類型(顏色) \ 名字空間 條目名字空間 檔案名字空間 討論名字空間
warning(red) 警告訊息和請求刪除 請求刪除
move(purple) 移動、拆分和合併 移動和重新命名 合併、拆分和重新命名
content(orange) 內容問題 嚴重警告和問題 大部分警告和提醒
style(yellow) 格式問題 較輕警告和問題 較小警告和提醒
protection(grey) 保護
version(blue) 版本 \ \
status(green) 狀態 \ \
notice(default) 條目注意 注意 通知和訊息
Star Zero · 維基假期中 2021年5月4日 (二) 11:33 (UTC) (最後編輯於2021年5月4日 (二) 11:35 (UTC))
模板已更新,各用到msgbox模板的模板需要單獨更新。MysticNebula70 T  2021年5月4日 (二) 13:28 (UTC)

是否應加入有關盔甲工具的重新導向

我最近在Wiki上進行某些條目的翻譯工作時,想使用和en一樣的重新導向(比如說[[Diamond Armor]][[Iron Armor]],均會被重新導向到[[Armor]]),但是發現中文Wiki除了皮革盔甲之外沒有其他相關的重新導向了。

如題,加入的理由有如下:

  1. 某些編輯者可能更傾向於輸入[[钻石盔甲]]而非[[盔甲|钻石盔甲]]
  2. 一些初來乍到的編輯者對Wiki是否有這樣的重新導向不熟悉,可能會直接輸入[[钻石盔甲]];發現Wiki上沒有這樣的重新導向之後,為了方便此編輯者可能會輸入钻石[[盔甲]],這樣不符合部分讀者的習慣——他們可能會在看不清楚的情況下點擊「鑽石」而非「盔甲」。

綜上,我認為有一定的必要加入相關重新導向,現在此提出意見,徵求社群的共識。--AblazeVase69188討論 | 貢獻) 2021年4月23日 (五) 14:18 (UTC)

如果需要的話,您可以自行加入重新導向。MysticNebula70 T  2021年4月23日 (五) 14:31 (UTC)
 支持 這種確實對新手會產生困擾,我以前也體會過hhhhh Yfohdit討論) 2021年4月23日 (五) 17:46 (UTC)

相關重新導向已全部建立,如有異議請在此提出。--AblazeVase69188討論 | 貢獻) 2021年4月30日 (五) 15:15 (UTC)

深層綠寶石(銅、煤)礦石的相關解釋需要改嗎?

如題,21w17a的資料包中已經可以生成這三種礦石的深層變種,但資料包的更新內容需要和正式更新內容一起寫嗎?--Minesunset1030討論) 2021年4月30日 (五) 22:15 (UTC)

資料包的內容不大可能和常規內容共存,因為它已經不屬於原始玩法。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:56 (UTC)

重寫LootChest模組

本人受中文McWiki管理員邀請,重寫LootChest模組,原模組有以下問題:

  1. 代碼雜亂,嚴重過長
  2. 資料結構複雜,維護困難
  3. 執行效率低

雖然原義只是修改後端代碼而不動前端顯示效果,但基於以下原因,我也一併進行了重構:

  1. 原模組生成的表格過長,對於大表較難對應左邊和上面的標尺。
  2. 原模組生成表格將不同結構合併為一張大表,導致浪費空間多。
  3. 移動端顯示效果差。

因此我預計進行以下變更:

  1. 將資料儲存方式變更為原檔案的格式(JSON),其他運算全部在模組內進行,不需要人工進行編輯。
  2. 提高了模組執行效率,從而可以一次性生成全部結構的表格,不需要儲物箱戰利品載入多個頁面的形式。
  3. 對於前端輸出顯示效果,一個結構輸出一個表格,透過flex佈局的形式進行合併,從而最佳化查找資料方便程度和移動端顯示效果。

目前重寫後的模組存在以下問題:

  1. 由於拆分table的原因,雖然提高了查找效率,但表格不對齊對於觀感有部分破壞。
  2. 由於重寫為非人工編寫的資料儲存方式,可能有個別功能無法繼承(大部分都可以繼承)。

目前已發現的問題:

  1. 部分物品和全部結構名無法進行轉換,將會加入轉換表進行轉換。
  2. 同一個大結構裡的不同儲物箱結構無法歸於同一個整體,這個可以人工分段解決。
  3. java開發版和基岩版後續會加入支持。

目前的資料儲存頁面:

目前的進度:

  • 結構輸出:指定結構
  • 結構輸出:全部結構 ?
  • 物品輸出:單個物品 X
  • 物品輸出:全部物品 X

目前的示例頁面:

  • 原始碼存放:模組:Sandbox/Star00/LootChest
  • 指定結構輸出:project:沙盒/LootChest
  • 全部結構輸出:Test wiki上的沙盒頁

由於未知原因,相同的代碼在mcwiki上無法實現效果,因此請先前往Test wiki進行查看。

請發表重構模組的建議,感激不盡。--Star Zero · 維基假期中 2021年5月1日 (六) 14:08 (UTC)

沒有什麼更好的建議了(在群裡都交流過了,但是似乎不太明朗),就 支持一下重構吧。EN那邊感覺也找不到人解釋。-- LakeJasonFace Lakejason0) 2021年5月1日 (六) 15:36 (UTC)
 支持重構,希望還能加入的一點就是java版和be版相同時的合併表格。--Snow dash & ) 2021年5月1日 (六) 16:16 (UTC)
 支持,見前面Sigma166/ 2021年5月2日 (日) 09:40 (UTC)
分為共有,java版,基岩版三個部分如何。--Star Zero · 維基假期中 2021年5月2日 (日) 09:57 (UTC)
 支持。--Minesunset1030討論) 2021年5月2日 (日) 10:16 (UTC)
 支持。也許可以用{{only|je}}{{only|be}}Sigma166/ 2021年5月2日 (日) 10:41 (UTC)
可否考慮i18n?方便維護也方便遷移到其他wiki。--RealCuervo討論) 2021年5月4日 (二) 16:36 (UTC)

修改Minecraft Wiki:管理制度

背景

中文Minecraft Wiki現行與過去的管理員選舉機制存在明顯錯誤和缺陷,為某些圖謀不軌的管理員施行專政封閉的管理提供了可乘之機。幾年前發生過的反pow團隊割裂現象,推進了管理制度的制定。但是,它反而成了管理員濫權的工具。因此,有必要重定管理員選舉制度,主要是管理員與巡查員的產生辦法。

原因
  • Minecraft Wiki:管理制度中所規定的「行政員保留無理由撤銷管理層職務的權利」」在職務到期時由行政員根據其表現決定是否刷新和延長時限」「不多於n名在職管理員對其就職提出反對」「3⁄4以上的在職管理員認可其對Wiki的貢獻。」使管理員可以「欽定」管理員、巡查員的就職和任免,嚴重違反了wiki社群共識高於一切的基本法。
  • 現今中文wiki社群環境已經成熟,共識系統可以確立,「人少」「效率低」已不是藉口。
修改辦法

Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。請善用比較功能查看差異。修改內容主要有:

  • 全面擯除專制選舉的陋制
  • 加入管理員投票選舉制度和巡查員符合要求即授予制度
  • 提高了巡查員和管理員的要求
總結

這是社群從選舉層面堅持和完善社群共識制度體系、確保wiki長治久安的必要之舉,充分體現了正當性和進步性。相信透過選舉制度的完善,Minecraft Wiki一定能夠走出長期存在的「專制泥沼」,集中精力完善內容、添磚加瓦,再創發展奇蹟。僅代表個人,不代表Fandom意見。希望得到各位的支持。-- Dianliang233 TC 16 2021年5月5日 (三) 03:14 (UTC)

 支持。我認為新的管理制度很好,提高了對管理人員申請的要求,也能有效防止「專制」的負面影響,等等。只有實行了更完善的管理制度才能讓我們的wiki變得更好。--Endearing Cat討論) 2021年5月5日 (三) 04:15 (UTC)(最後編輯於2021年5月5日 (三) 04:19 (UTC))
一個我比較擔心的一點是管理員並沒有CheckUser的權限——每一次都要申請職員去排除分身賬號是不現實的,加上Fandom註冊分身賬號極其容易,因此這種理論上較好的制度可能會因為這種原因而反應不出社群共識。-- LakeJasonFace Lakejason0) 2021年5月5日 (三) 04:23 (UTC)
同上,本人不認為只要是「自動確認使用者」就享有表決權,享有表決權應該設立以下限制:
  1. 必須是一名自動確認使用者
  2. 註冊時間須大於3個月,且總編輯數不少於50次
  3. 無重大封鎖記錄(違反Wiki條例且拒絕改正者須永久剝奪表決權)
滿足以上所有條件的使用者才能享有表決權。
以及,滿足以下任一條件的表決應被視為無效投票:
  1. 投票本身已經違反「一人一票」原則(例如重複投票和使用傀儡賬號投票)
  2. 沒有說明支持或反對原因
  3. 說明原因時離題或者使用不雅語言
  4. 投票後干擾別人的選擇,例如慫恿其改變想法等
為了保證本wiki的表決不受外界干擾,設立以上門檻是非常有必要的。--Lxazl5770zh.admin) 2021年5月5日 (三) 05:18 (UTC)
@Lakejason0Lxazl5770:意見剛剛已由本人加入到草稿。不過作為一個「投票」而不是「討論」,理由等還是免了吧。-- Dianliang233 TC 16 2021年5月5日 (三) 06:13 (UTC)
 支持修改管理制度。
但是本人也認為修改中的管理制度有上述的缺點,對表決權的擁有者的要求確實應該更高,以保證投票結果真實可信。能合理地選舉出巡查員、管理員和行政員的使用者應該在Wiki上活躍一段時間,對Wiki的內容和其他活躍社群成員有一定的了解,而且個人的品行也:不能讓其他社群成員感到反感。
由此提出下列關於對享有表決權的使用者的要求的建議:
  1. 是一名自動確認使用者
  2. 註冊時間超過三個月、總編輯數不少於70次
  3. 曾經在Wiki上活躍過至少一週時間
  4. 一個月內在Wiki上活躍過至少兩天
  5. 30天內無被封鎖記錄,一年內無被重大封鎖記錄(防編輯衝突等特殊原因除外)
此外,修改中的管理制度疑似沒有明確能夠正式成為巡查員的條件(如管理員的「在14日內,若至少70%的參與者支持,且沒有更多的真實爭議,則管理員申請透過」),在此提出疑問。--AblazeVase69188· 2021年5月5日 (三) 06:31 (UTC)
巡查員應該是達到條件直接給予的。不過還是有些問題,我近期會修正的。-- Dianliang233 TC 16 2021年5月6日 (四) 12:50 (UTC)
粗略地閱讀了一下新的管理制度,如果我沒猜錯的話,實際上是把行政員的權力架空了。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:46 (UTC)
  • 先從機制說起吧。明明在行政員的職責上寫著「賦予或撤銷使用者權限」,可是在流程上的任何地方都沒顯示和行政員有任何聯繫。按照你的流程,完全可以用一件外掛來替代,而且更高效便捷,提交者和投票者的資質審查完全可以交給機器處理且不會出錯。你的提案將行政員從「人」用規則束縛成了「機器」,這是對行政員的正當權利的直接損害,不可接受。
  • 談完機制談緣由。在幫助wiki對分配權限流程是這麼描述的:「如果你擁有許多管理員,你可能開始需要記錄過程管理他們的行為,例如,什麼時候應該保護一個頁面,還是不保護它好? 你甚至可能會達到一種情況——你需要一個檔案化程式來決定誰將成為一個管理員,以及應該撤銷誰的管理員權利,為了應付這種情況,你不妨提拔幾個使用者進入「行政員」使用者群組(少數你最信任的使用者)來管理分散提拔/撤銷管理員的工作量。在一些大型wiki上,使用者在被授予額外權限之前應由其他使用者投票決定,而管理組則透過指控委員會調查不當行為來撤銷其權利,除了最大的維基社群外,這些流程不太可能是必需的。」這其中明確指出行政員(按程式)有權限進行提拔和撤銷,而投票流程也可能不是必需的。這其中也沒有規定該程式需要「經過社群共識審批」,「嚴重違反了wiki基本法」的說法完全就是對它自身的歪曲解讀。
  • 在整篇提案中,你咄咄逼人地說「(現有制度)成了管理員濫權的工具」,「(wiki需要)走出長期存在的「專制泥沼」(來繼續發展)」,但完全沒有提供任何支撐,完全是紙上談兵。希望你能提供實例(不是「可能性」,而是已經發生的事實和資料)來證明現有制度被濫用,為什麼它與所謂的社群共識相左,它如何限制了發展(及發展的定義是什麼),和為什麼你的改革能確實地進行所謂的發展。

-- Powup333討論) 2021年5月5日 (三) 19:41 (UTC)

  • 管理員和行政員確實就應該是執行社群共識的機器。請問行政員的正當權益是什麼?行政員和管理員的權限,就是基於社群給予你的信任!別忘了你來自哪裏!

當不當管理員應該沒什麼大不了的。

——Jimmy
  • 最近聽說你wiki已經把社群自治列入wiki規則了?同上一條,要明白,wiki上一切使用者所有的權利都是共識給予的,你的權限同樣也應該是社群共識收回的。另外,help wiki作為權威參考我是絕對支持的,但是我認為某位使用者用來調侃我的話也同樣適用來回應你:

wiki不是可口可樂,不是全世界的wiki都有一樣的制度

——某位使用者
  • 如果有「實例」的話,你我還用在這裏長篇大論?為什麼現有制度可能是管理員濫權的工具我已經講的很明白了。潛在的問題就不是問題?至於你wiki管理層獨裁的事實證據那倒是有。鐵證都可以在一個叫做ag的使用者的言辭上看到。我是後輩,這方面您比我更有經驗吧?
個人言論,不代表Fandom。--34.92.62.159 2021年5月6日 (四) 12:40 (UTC)(最後編輯於2021年5月6日 (四) 13:23 (UTC))
忘記登入了,Dianliang233對此留言負責。-- Dianliang233 TC 16 2021年5月6日 (四) 12:43 (UTC)
「管理員和行政員確實就應該是執行社群共識的機器」這話我就不懂什麼意思了,既然這樣的話我覺得可以寫一個外掛讓它來當管理員,如果mw的執行機制允許這麼做的話。至於ag,欲加之罪,何患無辭呢(可以參考ag對某位名叫MashkJo的使用者發生的經歷)。
順帶提一提管理制度本身就有個缺陷:沒有規定管理員/行政員數量。這意味著只要實行所謂的「投票制」,理論上是可以無限增加管理員/行政員的數量的。但是我們都知道這樣做只會導致權力高度分散而出現拉幫結派(或者說所謂的「多黨制」)的場面,這顯然不利於wiki的健康發展。--Lxazl5770zh.admin) 2021年5月6日 (四) 13:36 (UTC)
  • 正是因為不可能實現才有的管理員。
  • 管理員數量確實不設限,但是能做管理員的使用者數量是有限的、社群自己的容忍度是有限的。-- Dianliang233 TC 16 2021年5月6日 (四) 21:01 (UTC)
  • 什麼叫正當權益?正道權益就是能在規則下行使權利的自由。打個銀行卡的比方,我有能在我賬號存取錢的正當權益,銀行可以設定限制說「一天最多取走一定金額」,「月底卡裡必須剩餘一定金額」,這也是銀行的正當權利。但銀行不能說「你無權自行進行存取操作」,「你必須在收到銀行通知後存取銀行規定的金額」。這合理嗎?這不合理。你的提案完全剝奪了行政員(在常態下)行使「賦予或撤銷使用者權限」的自由,這就叫損害了正當權益。
  • 那麼現在,就輪到你來解釋你的核心理念了,請你翻譯翻譯什麼叫社群共識。社群有多廣,共識又有多深?這社群是包括了上萬名的讀者,上千名的使用者,還是目前157名的活躍使用者,目前參與了目前話題討論的6個人?共識是指全體一致,絕對半數,三分之二,或是某百分比?過去的共識能否限制未來的共識,而未來的共識又能否推翻過去的共識?你又如何證明那不是現在的情況的另一個版本呢? Powup333討論) 2021年5月7日 (五) 05:16 (UTC)
Advertisement