模板:Sandbox/Chi ZJ2

在有人發現維護人員申請下有着可被歸類的提問後，這份可興可觀可群可怨的選輯便出現了。

相同內容的提問

你對萌百當下的議事機制及效率有何評價，有何改良建議？
User:Luoxuchan	放到年初我可能會說現在的議事機制沒有什麼問題，但現在恐怕不能這麼說了。雖然提案流程的規範和快速提案的出現讓萌百的政策修正變得非常簡便可行，提案或方針政策版一片欣欣向榮，但其他方面的不足如今也確實顯露： 萌娘百科對於突發事件和應急事件的處置能力向來不足，馬娘和BA事件常常讓維護組成員焦頭爛額，一討論就是大半天。這幾天我在其他的編輯組也經常看到有人討論BA事件，大概的說法是萌娘百科官方的發聲和處理都是暗戳戳還沒什麼章法的，就官方切片都咕了一兩天才做出來最後扔到一個巡查的用戶頁底下就再沒什麼動作了。就我之前的回答已經說過我不希望這種事情鬧大，不希望外宣那邊官方B站微博微信之類的下場，但現在這個樣子顯然也不是什麼最佳解決方法。這些事件讓我感覺整個運營和維護這邊都很拖沓，今天明天後天都在討論一個點，感覺缺少一個很核心的，願意淌渾水還具有公信力號召力的人站出來指個方向告訴我們究竟要怎麼做，結果就讓萌百的回應變成這種不足以扭轉輿論的樣子。什麼議會都要有一個議長，而維護組很多時候的內部議事完全是在大家都「平等」但註定沒什麼結果的雙方械鬥。 運維和普通編輯之間出現的一些割裂。在上面的回答我說過，有些時候，維護組其實是和廣大編輯者站在一起去面對運維的，比如 Moeskin 的上線讓很多人感到不解：「怎麼說上就上了，對社群意見的採納在哪裡？」這是一個運維方主推的事情，一旦是運維方推的事情，能探討的餘地就很小了。包括很多人對 Moeskin 提出的問題也是，維護組和普通編輯一樣對它出現的問題只能提報給運維（最多可能是提報途徑不同）但什麼都做不到，我們作為維護組看到有編輯在技術實現版提報關於 Moeskin 的 BUG 只能苦等黑卡回復，而回復也往往是「有待商榷」或者「至少要等半個月才能修復」，確實會讓人想提出「萌百是運維的萌百還是大家的萌百？」這樣的問題。我沒當過管理員，沒有在管理員的位置上看待過這一現象，但就我現在的視角來看萌百確實是在從一個社區共建的百科變成那種「資本」、「體制」的網站，換句話說萌百在運維參與的一些項目上確實不那麼平易近人了，我想這也是當前議事機制的另一個重大問題。 2022年6月15日
User:Leranjun	先說說議事機制的問題。 1029之後，我們看到了議事機制的很大變化。從政策上來講，非常多的大型議事政策（例如提案、投票等）被修訂，包括快速提案的制定對傳統提案的效率提升了不少。從結構上來講，我們看到了維護成員之間、以及維護組和其他用戶之間更多的互動，並且運維方面也更多地聽取了用戶的意見。這都說明我們在與時俱進，是好事。 但是如我在給星海的回答中提到的，目前的討論串、提案等方式還是很冗長，對於沒有精力密切關注的用戶不是很友好。一些討論串內容複雜、改動較多，經常會有用戶反饋「看不懂」；尤其是有票權的維護人員在活躍度壓力下，更容易發生「隨票」的現象。我希望在一些比較長的討論串（包括提案）里能有專門的地方維護更簡潔的TLDR版本，簡述「大概改了哪些方面」。比如，在比較複雜的討論串正文上方添加一個概要部分，由討論串發起人或對討論串內容主要關注的用戶概括討論內容，隨討論串中的討論更新。對於人事案，可以參考HW版史記的記錄方式，為比較長的回答列個提綱。就有點類似於GitHub上通過把上一個版本和這一個版本之間所有PR信息集合自動生成的更新日誌那樣，一個主要論點只要一句話就行，畢竟完整討論就在下面。我覺得這樣應該會更直觀。 舉個例子，如果我要對這個問題的回答做概要的話這何嘗不是一種套娃，可能會這麼寫： 總體上議事機制在不斷改進。 長討論串難以理解，建議增加概要部分。 缺少外宣緊急情況的應對方案，需要進一步商討對策。 站外編輯群討論的合「法」性存疑，應當保證站內的意見徵詢。 正如我在概要里所提到的，我認為另外一點比較重要的是突發事件的處理，尤其是外宣方面。這一點其實珞老師在他的申請里有提到，無論是馬娘還是BA，目前我們對於這種對外事件的處理方式依然沒有系統化，就連維護組內部獲取的信息也不完整。BA事件我是親眼所見，有人建議運維出面控制輿論、有人建議繼續談判、有人建議調查編輯組成員、還有人根本不知道發生了什麼，場面一度非常混亂。我是真心不想看到這種事情再發生一次。當然，這個話題牽扯到了編輯組的外宣能力和權限，我個人並不是最拿手的，但是我希望主要負責這塊的用戶（Siv）能夠格外注意制定對策，用最短的時間查明真相併做出處理動作，而不是讓我們被打得措手不及。另外，編輯組負責人也應當加強對組內用戶、尤其是新手的管理與指引，不要讓別人先抓住我們的把柄，導致一點小事被誇大、造謠，最後演變成公關危機。正如我在給二餅的回答中提到的，這個時候就體現出一個編輯組具有完備編輯指引和指南的重要性了。扯遠了。 最後一點就是編輯組內部討論的議事機制。很顯然，目前編輯組大部分都依賴站外群組作為主要溝通工具，而這也是有它的優勢的，畢竟即時通訊還是更方便、對新手更友好、也能提升討論速度。然而，尤其是一些比較大的編輯組裡，我有觀察到一些處於「灰色地帶」的討論：這些討論對站內內容進行了比較大的修改，卻沒有在站內留下痕跡，這實際上有違反MGP:編輯組指引中「沒有站內討論的情況下直接以編輯組的共識作為討論依據」的嫌疑。我就不說具體是什麼事兒了，不然感覺像在點名批評一樣，但是有些從該政策設立前遺留下來的一些討論習慣確實需要整改，保證編輯組政策的落實。我認為利用站外工具方便、效率高的特點達成初步的討論共識是沒問題的，但是涉及重大改動時必須在站內留下討論串，不能排斥沒有加入站外群組、或是對該「共識」可能有其他意見的用戶。不光是編輯組，這其實適用於任何一種站外討論。 2022年7月12日
User:TsanconBYin	這個問題得分兩方面回答。 常規議事，包括正常提案等，大部分都已經趨於完善且相當多的決策已經能夠公開化，除了專題編輯指引的相關更改的計票方式未有明文規定，目前默認了使用和提案一樣的計票方式，但個人認為尚存爭議，鑑於上一次想修這個的提案已經被否了，我暫且不提出別的意見。除此以外，對於目前要求維護人員集體參加相關議事的設定，雖然我是(＋)支持 的，但是也確實存在維護人員對相關事項不了解但是隨票的情況。且現在的制度可能不一定讓有相關經驗的編輯者有效參與討論（這一點在我主力的虛擬UP主專題尤為突出，已經有人指責專題指引是「少部分人的遊戲」了）。對以上的問題，我認為在短期內通過小修小補不可能改善，相關制度的強烈慣性會使得這種修改適得其反。但這不意味着隨着目前維護人員的增多我們就完全不去改變，我們假定以後巡查姬和管理員隊伍按照現在這個速率持續增多，那麼相對來說我們可能就需要稍微放寬一些對維護人員的要求，同時相應地稍微提升（或者維持也行）管理員就部分事項的決定性作用。（關於這部分我會在對劉君的回答中詳細闡明，為節省篇幅在此不表） 應急議事，包括危機公關之類的，我只能用兩個字形容：災難。馬娘組和BA組事件裡面，明顯可以由少部分維護人員以及運維解決的事情，到最後居然占掉了大部分維護人員的精力，且最後得到的結果也絕不能說滿意（雖然確實有對方的問題）。至於運維，尤其是在BA事件的處理中，我感受到了與維護組一樣的意見混亂。造成這種現象的原因，從維護組層面來說，是維護組本身的架構就決定了很多事情都是平面化交流，大家都是志願者，啥事兒都來攪合，這其實極大降低了辦事效率，所以對於這部分我們可能需要明確這些事情以後由誰接洽，其他人不要過多干涉。從運維角度說，沒有專業的公關團隊（或者明確的公關流程）這確實是一個致命傷，這是需要運維自己注意的，但考慮到運維目前正在進行的工作，我覺得是遙遙無期了。 2022年8月23日
你對萌百當下的用戶權限體系及當前維護組成員架構有何評價，有何改良建議？
User:泠佛.	萌百目前的用戶權限體系基本完備，但自確獲取難度低確實是存在的問題。另優編的覆蓋文件權限遲遲沒有實裝，若能儘早實裝該權限，可能會極大減輕維護組成員的工作。對於維護組而言，缺人是一直存在的問題，如何讓更多人嘗試加入維護組仍值得我們思考。 2022年3月6日
User:Leranjun	說一下比較常見的兩個類別的用戶組。 維護用戶組方面，能夠明顯感覺到的就是巡查人數明顯變多了。我認為大體上來看這是一件好事，因為維護人數的增加代表維護組意見更加多元化，並且越來越多的專題有對應的維護組成員負責，站務處理也更加便捷、高效。然而，在巡查申請增加的同時，巡查的定位也變得模糊了起來，給一些用戶一種巡查手裡的權限「不值錢」的錯覺。很明顯申請巡查的難度和管理、行政相比是不成比例地容易，而巡查和管理之間的權力差異相當大，從「條目維護者」直接上升成了「全站指引者」，沒有一個很好的過渡，因此巡查和管理之間的數量差異也越來越大。上一次修正案加入了維護人員提問和考核部分後，這個問題還稍微好了一點，但是實際操作中很少有人提問，多半是「申了就過」。當然，用RJ前輩的話說，我並不希望把巡查申請變成「政審」，也比較反感那種把每條貢獻都排查一遍、然後揪着早期的幾次編輯質疑的雞蛋裡挑骨頭的做法。但是我認為巡查的授權還是需要謹慎，畢竟是官方維護人員，手裡握着「掛刪」、「評論管理」等關鍵權限，並且能夠訪問維護組內部信息。這對於保持維護組信息透明其實也有好處——如果巡查的平均站務處理能力變低，導致整個維護組內很難進行重要的站務討論（或是沒有足夠的信任），相當於鼓勵管理、行政私下解決問題，又變成1029的情況。處理巡查申請的管理員一定要避免降低巡查申請的門檻、讓巡查變成「大號優編」。當然，我沒有說以上情況現在有發生，但是我不希望在未來發生。 技術用戶組方面，我認為「技編」、「腳編」和「界管」的添加尤其重要。這其實將技術用戶組和維護組做了一個分割，把一部分原來管理、巡查才有的技術權限（包括原來對重要模板的保護）下放給普通用戶，這對於沒有精力申請維護用戶組、但技術力較強的用戶提供了一個非常好的途徑來直接參與技術性內容的維護，而不用每次都讓其他不是很懂的管理員傳菜，是吧星海。但是星海技術力其實在不斷提高，可愛 2022年7月12日
User:TsanconBYin	同樣分兩方面來回答。 維護組方面的權限體系我原本不想做更多的評價與建議的，但就之前的「大申巡時代」以及MINGach、Zyszhao兩位未通過實習期，我認為我有必要指出，現在確實存在一種「巡查過熱」的傾向。雖然從我上一個回答中能稍微體現出一點我對維護人員隊伍壯大的希求，且巡查確實相比管理，算一個操作可逆度較大的權限組，但是就目前我們對巡查處理站務的有關要求，如果巡查注水，那對站務的處理也必然低質化，且畢竟巡查手裡還有個封禁權，還能繞過33，在授權這方面不得不慎重考慮。 一般用戶組方面，技術類我舉雙手雙腳贊成，將部分技術權限拆分出去這無疑是一個讓我這種毫無技術的人也有膽量申請管理的設置。爭論的焦點可能還是在優質編輯者相關的問題，我化用一下樂然申請管理員時的回答，就是優編在編輯者心中逐漸變成了一個「小號巡查」，很多人自申優編的時候都開始拿巡查的標準來套，這實在是離天下之大譜。對此有人說希望將優編重新改回巡查豁免，我覺得這樣造成的社群反彈會很大，但是相對應的我發現目前確實有利用過濾器實現「優編保護」的情況，因此我在想能否將優編直接改造成一個類似於手確之於自確的用戶組，所對標的是一個新設置的延確組或者這種情況是不是該叫做自動優編，以適應新的保護需要，同時也算是給優編一個相對來說配得上稱號的權限解決這種不平衡問題。 2022年8月23日
請您就管理員的權限及其設計談談對「System operator(Sysop)」和「Administrator(Admin)」這兩個詞的理解。
User:TsanconBYin	我個人的理解的話，前者是管理員權限列表的代表符號，後者則是管理員社群影響力與責任的一面。 2022年5月14日
User:Luoxuchan	我不懂英語。現在萌百的管理員是叫 SysOP，我覺得這個管理員就是一個比 Admin 更狹窄的東西，像 Windows 的計算機管理員就是 Admin，那個「Administrator」賬戶擁有能改變系統幾乎一切的權限，而萌百不行，萌百上頭還有行政員，或者說最大的問題是很多決策行政員也沒辦法拍板（後邊還有運維呢）。總而言之我認為萌百的管理本身沒有那種可以控制一切的條件，萌娘百科管理員不是山大王也不能是山大王，只是管理體系的一分子，這和 Windows 系統裡面那種統治一切的 Administrator 還是有很大不同的。 2022年6月15日
User:Leranjun	哦我的上帝啊，感謝聖母瑪利亞，我終於可以在這個地方看見英語了。老夥計，我敢跟你打賭，霍稀泥（Hoshimi）小姐根本就不懂英語，簡直就像老路德維希(註)路德維希·凡·貝多芬（德語：Ludwig van Beethoven；1770年12月16日－1827年3月26日），德意志作曲家、鋼琴演奏家。大談米開朗基羅一樣一派胡言——對了，你喜歡喝茶嗎？ 直譯的話，「sysop」表示「系統操作者」，「administrator」表示「管理者」。看一下詞源： Blend of system + operator. — wikt:sysop#English Borrowed from Latin operatōr, from operor (「work, labour」). Equivalent to operate + -or. — wikt:operator#English From Latin operātus, past participle of operārī (「to work, labor, toil, have effect」), from opus, operis (「work, labor」). — wikt:operate#English Borrowed from Latin administrātor (literally 「he that is near to attend」). — wikt:administrator#English From administrō (「attend upon, assist」), from ad- (「to」) + ministrō (「attend, manage」). — wikt:administrator#Latin From minister (「attendant」). — wikt:ministro#Latin 也就是說，sysop來自於「工作、勞動」，而administrator來自於「注意、協助」。 我認為其實這兩個詞描繪的是同一個職位的不同方面。從管理員的職務方面，sysop是「系統」的「操作者」，代表管理員的「執行力」。一個好的sysop需要保證操作合理得當，做出每一筆操作時都清楚原因和後果。尤其是在作出影響範圍較大的操作時（例如批量刪除替換、修改影響全站的過濾器及代碼等），應該謹慎謹慎再謹慎，儘量避免技術錯誤。從管理員的影響力方面，administrator是「服務者、管理者」，代表管理員在社群中的威信與職責。一個好的administrator需要保證自己在社群中有着與自己權力相符的信譽，才能做出有益於社群、提升社群滿意度的事情。我再重申一遍，群眾是監督的力量，也是管理者執政的基礎，一個不為普通用戶着想的管理者不會被社群所信任，也不可能有領導、指引社群的能力，更別說處理社群事物了。 2022年7月9日
在萌百當下的維護人員的用戶權限體系及當前維護人員架構下，我們對維護人員在出現重大站務時參與度有較高的要求，這對專注於一個或數個特定領域/主題的維護人員是不太友好的。那麼您認為這種讓所有維護人員都參與到站務中來的思想是否有其局限性和改進空間呢？
User:AnnAngela	身在其位應謀其事，在現在擁有技術編輯組的情況下，維護人員應更集中於站務方面的參與，我不覺得該思想有其劣勢，至多是相關制度應應時調整； 2022年1月3日
User:泠佛.	管理員擁有很多高級權限，如更改巡查姬等用戶組、大量刪除頁面等；也擁有部分涉及用戶隱私的權限，如查看、修改私有過濾器等。所以對申請人提出了很高的要求，其必須擁有獨立思考、判斷能力，能夠傾聽社群的意見，被社群信任。 2022年3月6日
User:雲霞	我的看法如下： 就巡查姬而言，實際上除了重大事項的投票之外，沒有要求巡查姬做太多的、額外的全站站務的關注事務，傳統上巡查姬的提權往往也是由於對某幾個領域的優秀編輯而得到能力上的認定的。 對於管理員而言，以目前來說管理員的數量是嚴重不足的（甚至可以說是歷史以來比例的最低值），這很大程度上是對管理員的要求所導致的。 不過我也認為，在技術用戶組拆分之後，管理員申請所需要的技術門檻降低了。可以鼓勵更多對站務感興趣，同時有一定站務能力的巡查姬加入管理員團隊，這是一件好事。另外目前隨着方針政策的細化（我不是很認同「細化」這一趨勢）以及技術用戶組的實行，也需要更多的管理員「分管」各個站務方向，這個問題我認為正在變得逐漸迫切。 對於局限性和改進空間的問題，我認為是一個循序漸進的過程：只有管理員數量逐漸提高的時候，在站務上才可以逐步降低對管理員「全部參與」的要求——我也認為很多目前的巡查具有成為管理員的潛質。 2022年2月7日
User:TsanconBYin	能面面俱到的人我覺得是不存在的，比起讓人閉門造車，給所有維護人員設置一個義務去關注其他方面，或者至少看一眼，未嘗不可。更好的制度或許存在，但是有沒有可執行力我得打一個問號。 2022年5月14日
User:Luoxuchan	我認為只要是維護組成員就應具備對整個站點的，一定的信息掌控能力（並不是說要什麼都了解透徹，至少知道有這麼個事兒），而且「重大站務」（包括影響活躍度的投票、一些類似1029的處罰決定）影響力是波及整個站點的，即使維護組成員在進入維護組之前編輯範圍非常局限，在作為維護組成員之後對這些很重大的需要全體維護組成員參與的事情都應該有一定的了解和自己的想法。所以我覺得現階段的參與度要求並不是什麼問題。而且我本身也是窄範圍維護組成員，對這種事情還算應付得來（何況還有至多連續三次的不發表意見的次數可用）。 2022年6月15日
User:Leranjun	稍微分三個部分回答。 我認為「讓所有維護人員都參與到站務中來」這個思路是正確的。作為維護人員，本來就應該對各種站務處理都有經驗。即便是對於像我這樣編輯範圍一隻手能數的過來的維護人員，萬一類似的事情發生在自己主要維護的條目上怎麼辦？ 3次投票的活躍度要求，我覺得還行，基本上夠用，也很少看到有人因為這個被撤職。但是我有一點顧慮，就是會不會因為活躍度要求而導致濁華前輩上面所說的「隨票」的情況。不管是因為忙還是因為對內容不感興趣，一定有不想完整閱讀提案和人事申請討論串、但是由於活躍度要求不能投棄權而不得不按照「大趨勢」來投票的情況，這個時候就很難聽見反對聲音。我之前確實是有體驗過短期忙碌、又不到請辭程度的時期，如果趕上提案和申請密集就會相當麻煩。或許可以考慮在3次的基礎上加上時間限制？例如3次未投票間隔大於等於14天之類的。當然，只是個想法。 至於其他的「重大站務」，尤其是公關和外宣方面，大部分維護人員能夠參與的程度也比較有限，主要還是需要與運維和行政商量。 2022年7月9日
在理性權衡利弊的前提下，如果跳出方針/指引的框架去做某些事情會得到更好的效果（即所謂的「濫權」），您是否會選擇去做？如果是，請說說大致會怎麼去做；如果為否，請說明原因。
User:Luoxuchan	就我個人而言會比較嚴格的遵照方針和指引的框架，最多可能會仔細去摳方針指引的內容做一些能從政策文件上解釋通的事情，但是直接跳脫出這個框架來濫權會比較困難。上文我闡述了自己的一個觀點，即管理員不是山大王，確需濫權的話這種事情還輪不到我做，或者，輪不到我僅憑自己的判斷去做。我認為自己的主觀判斷不可靠，如果有複數個管理員和我持同樣的觀點，去執行這個「濫權」的大概也不會是我。 2022年6月15日
User:Leranjun	我認為「理性權衡利弊」的前提下不會出現「跳出方針/指引的框架」的濫權——如果有，說明方針政策出大問題。以目前的政策文件來看，基本上都有兜底條款，很難真的跳出這個框架執法。目前我所見到過的「濫權」頂多就是在一些細節上——比如撤銷或回退編輯、判定條目質量、封禁破壞者這種有主觀因素存在的操作里——夾帶一些私貨，但是這種情況也主要以方針政策為基準。我個人會儘量在日誌里留下相關政策的鏈接，這樣一方面可以justify這類操作的合法性，另一方面也能提醒那些因不了解政策而犯錯的編輯者、幫助他們認識到自己的錯誤，而不是只是讓他們認為我在「濫權」，然後下次被其他維護人員警告。退一萬步講，就算真的遇到方針政策解釋不了的問題，我也認為應該先向其他維護人員求助，而不是冒失地進行可能會「濫權」的操作。說不定真的就是方針政策需要修改了呢？ 2022年7月9日
如何看待各類申請提問中的「為問而問」的現象，以及您有何建議或意見用以改善「沒回答提問→投反對票」這種邏輯錯誤的情形。