維基百科:互助客棧/其他/存檔/2022年6月

糾正歷史上陰陽家的錯誤

雪球關閉：

請閣下勿於此發表離題內容。 --紹💓煦^{意見箱 · sign} 2022年6月5日 (日) 19:27 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

很不幸的是歷史上這種前人的錯誤，不是我們後人能糾正的。

一個中國文化的特徵而世上也是獨一無二的，那就是中國古代的陰陽學。陰陽學的晢理至深，一般世人無法了解，以訛傳訛，傳至其末，「不知所云」，屬性與本質是兩碼事。這種前人的錯誤，不是我們後人能糾正的，在這裡我們沒有理由去追求那些「以訛傳訛」 的陰陽屬性，那只能越描越黑。我們必需從新來過。

根據太極圖，那不是兩個蝌蚪擠在一個圓圈裡，而是一對黑白象徵性的代表一個陰陽整體，黑裡一點白，白裡一點黑，隱藏著「陰陽錯」的天機（「錯」 作交錯或是錯過解）。

https://upload.wikimedia.org/wikipedia/commons/1/17/Yin_yang.svg

見圖，陰陽表現四個不同又相關又不能分的特性： 一）對立統一。那是陰陽相對而形成一體。 二）相剋相生。陰長克陽，同時助陽復生，反之亦然。 三）物極必反。陰極變陽，而陽極變陰。 四）極盡平衡。極盡—最終—陰陽總是平衡的；那是說，陰陽總是追尋平衡的。

那「四個不同又相關而不能分的特性」 是個很高深的學問，世人不能理解，謂之詭譎/邪術，終於在魏晉朝時代失傳，只有一個太極圖和一些陰陽的「屬性」 （裡外，上下，男女等等） 留傳下來。

用語言吾人可以定義任何事物，但是它存在嗎？定義沒有實物與其對應只是一個幻想。根據上述陰陽的特性，陰陽是不能分的，所以是「一元」 ，當陰陽家創「陰陽二元論」 時，陰陽一元的本質盡失，陰陽家是始作俑者，後世跟著錯。那什麼是真正的陰陽呢？「陰入陽出」 ，呼吸也。世上萬物，只有呼吸附合那四個陰陽的特性，呼吸是「一元」 世界的元素，二元世界不過是一元世界的幻想。

証明：一）對立統一：吾人呼吸，一呼一吸，然後循環，我們不能只呼不吸，或是只吸不呼，所以呼吸是不能分的一體—「一元」—對立統一。 二）相剋相生：當我們吸氣時，越吸越難吸，同時呼氣比較容易，那是吸氣克呼氣，同時助呼氣復生—相剋相生。 三）物極必反：當我們吸氣吸到盡頭不能再吸的時候（物極），必然呼氣，反之亦然—物極必反。 四）極盡平衡：吾人要是活著，呼吸一定平衡—極盡平衡。

陰陽二元論說不定是一門學問，但是其主題的對象不是我們中國古典的陰陽一元論的陰陽。 --太極滑雪（留言） 2022年6月4日 (六) 18:32 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

在谷歌搜尋維基百科論述疑似被劫持

在谷歌搜尋維基百科:熱血速刪,發現搜索結果被劫持到一個叫「barang.live」的網址，裡面的內容不可描述。

不知道其他用戶是否也遇到了這個情況，是否還有其它的維基百科搜索結果在谷歌被劫持？--Hooonooka（留言） 2022年6月1日 (三) 08:39 (UTC)

動態鏡像加有SEO。好像有討論過，但好像沒有辦法讓Google對待我們站點更友好。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年6月1日 (三) 08:59 (UTC)

之前有過。這並不能算「劫持」，僅僅是Google收錄了鏡像站的結果且排名更靠前而已。

辦法嘛，我沒記錯的話萌娘百科通過JavaScript實現了如果通過鏡像網站訪問，會顯示提示。不知道本站有沒有意向部署類似功能？或許可以在一定程度上解決此問題。--Tranve (✉) 2022年6月2日 (四) 13:20 (UTC)

如果找知名人物，事件，品牌和與自己地區相關的事物和愛好者相關的條目，Google搜尋結果會放在非常前的位置。不過如果要找海外的景點資料，Google搜尋結果找KOL和博客比較多，維基基本放在很後的位置。--Wpcpey（留言） 2022年6月2日 (四) 14:27 (UTC)

應該請基金會聯繫Google。--虹易（留言） 2022年6月9日 (四) 04:49 (UTC)

重啟逐筆巡查標記的討論

已通過：

後續請見phab工單T308976。 MilkyDefer 2022年5月22日 (日) 12:57 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

如題，之前有提過是否能對每一筆編輯進行逐筆巡查的標記，以避免巡查員重複巡查同一篇文章的問題，不過好像最後結論就不了了之，因此希望能重啟討論。

在前一篇討論中，有很多人擔心巡查人力的問題，這部分我回覆一下，就是因為現行巡查人力不足，所以我們更應該改善巡查的效率，讓每位巡查員一打開巡查頁面就能知道什麼編輯尚未審查，而不是像現在一樣每筆點開來看，如同大海撈針。至於擔心巡查員積壓工作的問題，我想這並不是一個很好的理由，逐筆巡查對反破壞工作來說非常重要，並不是說不打開這個工具就可以當作現在這個工作不存在。--Koala0090（留言） 2022年5月8日 (日) 03:56 (UTC)

先是技術上是否支持，其次是用法和是否可靠。如權限下放程度，是否允許機器人/批量標記巡查，標記不當（應該有日誌吧？）是否要追問質詢、如何應對增加的「煮」。如果啟用/禁用手續不複雜，試行也無妨。其實最近更改巡查也挺好，每個人對修訂是否得當的標準不同；或者，逐筆巡查主要應對隱秘的鬼祟破壞？--YFdyh000（留言） 2022年5月8日 (日) 04:20 (UTC)

之前@Xiplus：好像有說技術上有可能辦得到，不過機器人批量巡查這件事我不確定能不能。我是覺得可以試行兩周個幾次，如果沒問題就全面適用。--Koala0090（留言） 2022年5月8日 (日) 05:05 (UTC)

主要是逐筆標記巡查有何意義？有不同於Wikipedia:穩定版本功能（好像由於技術原因，不會再追加功能新開站點）可以控制顯示標記後的顯示頁面。新頁面巡查好歹被視為具有權限性的職務，而最近更新巡查是人都可以巡查，是否標記的意義不大。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月9日 (一) 09:41 (UTC)

意義可能是減少重複檢查，提升對冷門條目的檢查率。--YFdyh000（留言） 2022年5月9日 (一) 09:46 (UTC)

想到一個弊端，破壞者可能根據條目修訂長期無人「巡查」而採取鬼祟破壞，不知道是否有應對之策，就像條目監視者太少時不具體顯示。--YFdyh000（留言） 2022年5月9日 (一) 09:48 (UTC)

@Cwek沒有標記的話，打開最近更改只能望洋興嘆，根本不知道從何檢查起。如果有標記的話，至少我一登入就知道我要檢查哪些編輯。--Koala0090（留言） 2022年5月9日 (一) 09:54 (UTC)

最近更改的過濾器功能現在挺強的。可以用最近更改-「監視列表新更改」過濾器。--YFdyh000（留言） 2022年5月9日 (一) 09:59 (UTC)

我目前是這樣做沒錯，但這一樣會有重工的問題--Koala0090（留言） 2022年5月9日 (一) 10:13 (UTC)

最近更新和監視列表有個修訂評分功能，會自動標記可能是壞質量的修訂版本，可以試試打開。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月9日 (一) 10:32 (UTC)

我有開，但感覺不知道評斷依據是什麼？而且似乎大多數的破壞反而都不在標記中。另外會需要蹲點巡查就是因為有些蓄意破壞很難透過位元組或用戶加入時間去判斷。--Koala0090（留言） 2022年5月9日 (一) 18:08 (UTC)

那也沒辦法，有些破壞行為是偶然看條目發現不對勁才去翻查頁面歷史的，不可能靠整天蹲著最近更新來「掃描」（好吧，雖然有工具是可以這麼幹的），要不然這是嚴重的中毒了。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月9日 (一) 23:33 (UTC)

所以有什麼具體不能開放的缺點嗎，理論上巡查工具應該是越多越好，如果技術上可行，又沒有什麼缺點就開著，想用的人就用，不想用的人不用也沒關係吧。--Koala0090（留言） 2022年5月11日 (三) 09:25 (UTC)

• 儘速啟用。->>Vocal&Guitar->>_留言 2022年5月12日 (四) 23:45 (UTC)

如果技術允許的話，建議將所有延伸確認用戶的編輯自動標記為已巡查。否則打開最近更改看到一大片未標記的編輯，更沒有動力去標記了。--Steven Sun（留言） 2022年5月15日 (日) 01:59 (UTC)

看了之前的討論，技術上似乎無法區分新頁面巡查豁免和編輯巡查豁免。--Steven Sun（留言） 2022年5月15日 (日) 02:11 (UTC)

可以開發機器人來自動標記。--YFdyh000（留言） 2022年5月15日 (日) 04:00 (UTC)

@Xiplus：想請問技術上是否能達成？若能達成，是否還需經表決，還是直接當成小工具開啟即可。---Koala0090（留言） 2022年5月15日 (日) 04:36 (UTC)

哪個部分？--Xiplus#Talk 2022年5月15日 (日) 04:42 (UTC)

@Xiplus 開啟逐筆巡查以及利用機器人標記巡查豁免者--Koala0090（留言） 2022年5月15日 (日) 06:25 (UTC)

我覺得可以開啊，但我覺得沒必要用機器人自動巡查，最近更改本來就可以篩選30/500，跟90/500也差不多吧，用這個就行了。--Xiplus#Talk 2022年5月15日 (日) 06:30 (UTC)

@Xiplus感謝回覆，那如果要啟用的話需先經過表決，還是要經過什麼討論步驟嗎？--Koala0090（留言） 2022年5月15日 (日) 09:18 (UTC)

公示數日即可--Xiplus#Talk 2022年5月15日 (日) 09:31 (UTC)

自即日起公示七日，若無其他反對意見，則開啟逐筆巡查功能。---Koala0090（留言） 2022年5月15日 (日) 12:57 (UTC)

先試三個月看看好不好？直接一次通過我擔心沒能完全消掉社群的疑慮。--Ghren🐦🕙 2022年5月15日 (日) 14:31 (UTC)

不需要定死時間吧，有共識再關閉。開關都需要phab那邊完成。--YFdyh000（留言） 2022年5月15日 (日) 22:35 (UTC)

技術層面上，這個功能能夠啟用嗎？（已經發生過多次搞不清楚狀況，最後提交到phab那裡被拒。。。）--百無一用是書生 (☎) 2022年5月18日 (三) 02:39 (UTC)

@Xiplus屆時是否可以協助提交請求呢？--Koala0090（留言） 2022年5月18日 (三) 03:19 (UTC)

好。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)

近百個wiki開啟此功能。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

感覺啟用後實在沒啥意義，全都是紅色感嘆號，而且修訂歷史裡還沒有這個標記，只有最近更改和監視列表里才有--百無一用是書生 (☎) 2022年5月23日 (一) 14:56 (UTC)

目前看來回退和復原後並不會自動標記已巡查，若是如此，認為可能需要提醒所有巡查員要記得點選已巡查，不然還是要每筆點開來看。Koala0090--0906_{（回復請Ping我）} 2022年5月23日 (一) 16:30 (UTC)

對我也發現這個問題了，有辦法將某些設定設定為自動巡查嗎，例如說回退之類的。--Koala0090（留言） 2022年5月23日 (一) 16:32 (UTC)

另外就是因為我有開啟小工具，可以在不點開畫面的狀況下進行依些簡單的巡查。但因為最新更改清單中沒有巡查按鈕，還是要點進去才能巡查。不知道之後可不可以在後面加上一個巡查按鈕--Koala0090（留言） 2022年5月23日 (一) 16:37 (UTC)

Xiplus如果使用TW不知道可否自動標記，還有管理員、機器人應該可以自動免巡查吧....--0906_{（回復請Ping我）} 2022年5月23日 (一) 18:57 (UTC)

@ChhTJ096：全都是靠外部腳本運作的配套功能，為什麼要靠腳本來清除？所以說，這個功能，為什麼不從一開始就考慮解決後續的問題（一些用戶或者大部分用戶並不需要這些標記，或者說還需要考慮部分用戶組的編輯可能不需要被這樣標記）。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 02:21 (UTC)

很困惑的雞肋功能，而且還要靠額外的手段來清理掉一些不必要的標識。只為其中一位編輯的識別能力弱而特此開啟該功能，真的是……——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 01:45 (UTC)

祝某些編輯「消消樂」愉快。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 01:49 (UTC)

沒價值的引戰留言恕我不回覆了--Koala0090（留言） 2022年5月24日 (二) 06:22 (UTC)

建議撤銷該操作

正如所見，這個標記功能很雞肋，而且觀感糟糕（最近更新和監視列表全是嘆號），一系列解決方案（包括機器人自動標記、延伸確認用戶自動標記）都沒有跟上。所以沒必要開啟，如果特定編輯需要為每筆編輯標記以防止漏查，親，我建議你自己寫工具更好，畢竟是自己動手豐衣足食。@Shizhao、Steven Sun、YFdyh000：如果認為該功能作用不大，應該考慮撤銷掉。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 02:13 (UTC)

暫時來看，具有「新頁面巡查」、「巡查豁免」，或者說用戶組具有標記巡查功能，的編輯是沒有嘆號的，也就是自動標記的。有可能這本身和「新頁面巡查」的巡查機制是同一套的。Wikipedia:最近更改巡查也僅僅是提供一些外部追蹤工具的志願工作，而不是具有權限組的「職能」，為此開啟這個功能有點用大炮打蚊子？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 02:37 (UTC)

另外，去了部分開啟這個功能的wiki項目（波斯語fa，義大利語it，C區commons），fa和it的最近更新沒看到有嘆號，同時我沒有當地類似巡查的職能性權限，可以認為沒有「標記巡查」功能的用戶是不會看到「嘆號」的。commons的最近更新基本上沒見到嘆號，而且我有當地的「自動巡查」組，我就納悶，然後再對了一下，一來分是大部分編輯都具有「巡查標記」功能的用戶組，所以前述，會自動標記巡查；二來新頁面巡查似乎也清得很勤快，沒有對應用戶組的用戶的編輯很快被清理了；三來留意到一個bot帳戶User:BotLeo，會將新加入的「自動巡查」組的用戶的舊編輯全部標記為已巡查。如果要達到不干擾的情況下，至少要做到commons區的情況才行。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 03:15 (UTC)

其實本來這個狀況就是有預期到的，首先開啟第一天，有許多巡查員尚不知有這個功能；第二就是這個工具缺乏自動標記功能。如果要解決的話應該是可以透過改善自動標記某些巡查功能，真的不能做到再關閉。每個新工具上線之初本來就會有問題，本來就需要一段時間的測試和調整。每個人的需求不同，如果因為你個人「不需要用到」這個因素而去阻止其他新工具的開發，那其實對於整個社群的進步是有危害的。例如說視覺化編輯上線初期，也是出現了很多反對的聲音，有些人說「原始碼用得好好的，為什麼要開發這麼難用的工具！」但對於許多不會原始碼的新手，這個工具還是相當重要的，如果還是用你那論調主張「只有少部分程式語言能力低落的用戶需要用到」，那就會阻礙很多人參與和工作。總之，言盡於此，若閣下後續有價值的留言我會適予回覆，單純來引戰和人身攻擊的就上ANM，這樣。--Koala0090（留言） 2022年5月24日 (二) 06:37 (UTC)

「『我』不需要用到」不等於「你需要用到就啟用」，而且我也留意到一些用戶也疑惑啟用的必要性。而且「最近巡查」並不是「點擊標記」，且不依賴於「點擊標記」，你的想法是假設有最近巡查的人員會重複巡查，但問題當發現懷疑破壞後，不應該直接點擊差異進去看一下有沒之後的編輯（可能有其他用戶已經發現而撤回，又或者不只是這一筆還有後續）？只要能做到這步，就不會出現重複巡查的問題（因為前述，如果沒被處理就肯定這個「破壞」處理或者還有後續，這就更需要看頁面歷史），所以這個最近更改的標記就沒有意義。而且沒有CSS修飾的話，的確可以肯定已經對眾多有巡查權限的用戶造成困擾，而且我不認同靠CSS來掩耳盜鈴來處理（甚至沒有其他mw-core的功能配套下，依靠外部的行動來標記「可信」的編輯）。如果只是某些編輯為了防止自己的失誤的話，應該自行解決，而不應該用大炮打蚊子的方法，還要搞出額外的操作來換更小的大炮打蚊子來避免。甚至最近巡查真靠逐個標記來排除破壞，而不是通過觀察編輯行為來判斷？———Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 09:49 (UTC)

所以你根本沒有搞清楚為什麼需要開啟這個工具，你說的重複巡查跟我說的重複巡查根本是不一樣的東西。你說的是重複反破壞，但至於重複審閱的問題根本沒有解決，開啟這個工具的目標並不是防止失誤，而是可以讓巡查員一眼看出哪些編輯還沒巡過，可以更有效率地去找。

第一天許多巡查員根本還沒進入狀況投入巡查，本來就預期會有這樣的情形，但我們卻必須花大把的時間跟你解釋這個是本來就會發生的狀況。--Koala0090（留言） 2022年5月24日 (二) 11:00 (UTC)

反而你沒搞清楚WP:新頁面巡查和Wikipedia:最近更改巡查的差異（一個是具有職權性的（有專屬的用戶組），另一個是只需要配合工具任何人都可以參與的志願工作），而且「最近巡查」處理完破壞後還要手工點擊「標記」多此一舉的行為。所以我只能說你不過沉迷於「消消樂」的遊戲，給有「巡查標記」功能的「新頁面巡查」帶來困惑罷了。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 01:02 (UTC)

別瞎代表，是「你」。根據行文來看，Shizhao似乎對此有不太贊同或疑惑的意思。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 01:14 (UTC)

「最近逐筆巡查標記」的問題是，對於沒問題的編輯版本，依然依靠「標記」來消去提醒，在大部分編輯沒問題的情況，這可能是困擾性的。不同於「新頁面巡查」，「標記巡查 」對於其他「新頁面巡查人員」來避免重複新頁面巡查來說，才是有必要性的。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 01:26 (UTC)

既然知道這是同源技術，那麼新頁面巡查就是巡查這個頁面的第1筆編輯，最近更改巡查就是巡查這個頁面的第2、3、4筆編輯，實際並無差異。就算已經有巡查員群組，所有人都還是可以參與新頁面巡查，而巡查權限本質上只是一個「告知其他人不需要再檢查一遍這個條目」的權力而已，同理，提案人只是需要「告知其他人不需要再檢查一遍這個編輯」的功能。--Xiplus#Talk 2022年5月25日 (三) 03:09 (UTC)

Wikipedia:新頁面巡查是職權性的（具有獨立的用戶組和功能），Wikipedia:最近更改巡查是帶有志願性和非職權性的，實際上「逐筆巡查」的功能是「新頁面巡查」用戶組及職權下所擁有的功能（或者說附帶的，由於啟用了逐筆巡查且技術同源），對於普通用戶而言，逐筆編輯除了撤銷破壞之外，就沒有任何功能的操作的，而新頁面巡查有著更多的操作（分析頁面並且掛標示或者編輯改善），而且有著功能性的操作——將第一筆標記以便於清除提醒。所以對於「最近巡查」而言，有沒這個功能（是否標記）無關重要，對於「新頁面巡查」用戶組而言，只是多了「最近巡查」的附帶功能，而且對於想執行「最近巡查」的用戶，「需要」這個功能還不如就是申請成為「新頁面巡查」用戶組人員。而且基於兩次提案實際上看上去更像是Koala0090的一己之欲，支持者也不多（或者更多的是認為功能是否必要或者有不太可行的附加要求），所以看不出這樣的功能開啟共識有多強。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 04:26 (UTC)

或者說，對於大部分擁有「巡查標記」功能的「新頁面巡查」人員來說，「逐筆標記」是否具有必要性；而對於想執行「最近更新巡查」的用戶來說，「逐筆標記」是否具有必要性，另外如果為了這個「逐筆標記」的能力，是否其實應該考慮成為「新頁面巡查」人員？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 04:30 (UTC)

「新頁面巡查有著更多的操作（分析頁面並且掛標示或者編輯改善）」難道一個文字內容在建立頁面時需要掛模板，但如果建立條目一段時間後再加入同樣的文字內容就不用掛模板嗎？--Xiplus#Talk 2022年5月25日 (三) 04:32 (UTC)

特定一筆編輯「掛修葺標示」和「標記巡查」在「Wikipedia:最近更改巡查」中有必要的關聯？或者說，有必要每一筆編輯操作都需要人力確認有問題或者沒問題，來消除這個巡查提醒？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 04:36 (UTC)

Re「有必要每一筆編輯操作都需要人力確認有問題或者沒問題」：沒有檢查到就算了，這同理於存在積壓的新頁面巡查，所以我們才需要「標記功能」來讓僅有的人力效益最大化，如果每個巡查員每天能巡查10個條目，那麼2個巡查員最多可以巡查20個條目，如果沒有將新條目標記為已巡查的功能，那麼這2位巡查員就可能檢查到重複的條目，導致總巡查量降低。同理如果有2位志願巡查最近更改的人，而分別每天能檢查100筆編輯，那總檢查量最高是200編輯，但如果沒有將編輯標記為已巡查的功能，那麼這2位檢查到重複的編輯，就會讓總檢查量降低。--Xiplus#Talk 2022年5月25日 (三) 04:44 (UTC)

我認為還是一個問題，沒搞清楚WP:新頁面巡查和Wikipedia:最近更改巡查的意義，原則上新條目應該被標記巡查掉（現在就是人力原因或者其他原因，導致了經常超期，而且也不會影響條目的顯示），「標記掉」就是「暗示」給其他「新頁面巡查」人員這個條目已經巡查過。而執行「最近更改巡查」工作的用戶，添加了修葺標識、撤銷了一筆破壞，與「標記掉」有沒必要的關聯？沒有，而且看是否存在後續編輯就知道是否被處理過。而且也提及過，由於技術同源，這個功能是對「新頁面巡查」人員有影響也只對「新頁面巡查」人員有意義，但對於「新頁面巡查」人員來說，這個功能（連「逐筆編輯」都可以或者需要標記巡查）是否具有必要性？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 04:55 (UTC)

「而且看是否存在後續編輯就知道是否被處理過」為什麼我必須要點進去才知道有沒有被處理過，對於不需回退的正常編輯，也不可能有後續編輯。巡查新頁面同理，我如果點進去10個條目都發現已經被掛快速刪除模板，這是否表示巡查沒有積壓，並不是，這只是表示我巡查了其他人已經巡查過的條目。--Xiplus#Talk 2022年5月25日 (三) 05:02 (UTC)

簡單問：Special:最新頁面裡面的「隱藏巡查過的編輯」意義是什麼？您巡查時會使用此功能嗎？為什麼要使用？--Xiplus#Talk 2022年5月25日 (三) 05:08 (UTC)

如果針對最近更新的編輯，如果發現有問題的編輯，點擊差異進去，確認是有問題了，直接撤銷掉，然後還要回去上一筆編輯，點擊標記（對於具有「巡查標記」功能的用戶，例如「新頁面巡查」組的）；或者然後可以什麼都不用干（對於沒有「巡查標記」功能但又想干「最近巡查」的用戶）。而對於已經處理了的編輯（即使像過去一樣，沒有「逐筆標記」功能），沒點擊差異進去之前，最近更新已經提示有下一筆編輯了；點擊差異進去，如果已經處理了，同樣顯示已經有下一筆版本；或者操作撤銷時，提示有編輯衝突，因為類似的操作已經被另一位用戶同樣處理了。最終回到這裡，「逐筆標記」似乎變得可以沒有的存在，因為整個行為只對「新頁面巡查」組有功能意義，但又不是必要的操作。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 05:29 (UTC)

「沒點擊差異進去之前，最近更新已經提示有下一筆編輯了」那如果沒有下一筆編輯，但這筆編輯實際上已經由別人檢查過的話呢？--Xiplus#Talk 2022年5月25日 (三) 06:29 (UTC)

如果是好編輯，那就別管它，關掉窗口或者忽略掉就是了。如果是壞編輯，請行動，或者已經有人行動了。「逐筆標記」並非必要。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 07:18 (UTC)

您一直沒有理解我的重點，我為什麼要重複檢查別人實際上已經檢查過的編輯？為什麼不能直接排除掉別人檢查過的編輯？--Xiplus#Talk 2022年5月25日 (三) 07:29 (UTC)

重申：點進去一筆編輯後才發現別人已經檢查過就算重複工作了，別人檢查過的編輯要直接隱藏！--Xiplus#Talk 2022年5月25日 (三) 07:30 (UTC)

那問題是這樣做有意義嗎？然後讓一個對Wikipedia:最近更改巡查有興趣的用戶，特意去申請加入「Wikipedia:新頁面巡查」去獲得「標記巡查」功能，然後就是為了給沒有問題的編輯做標記，然後通過這樣告訴其他「Wikipedia:新頁面巡查」人員「哦，這個編輯沒問題，這個編輯也沒有問題，這些編輯也沒有問題」？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 09:18 (UTC)

有必要的話會進行權限拆分。--Xiplus#Talk 2022年5月25日 (三) 09:30 (UTC)

Wikipedia:最近更改巡查沒有用戶組，而Wikipedia:新頁面巡查關聯的用戶組「巡查員」的核心權限就是「patrol」功能權限，也就是想做Wikipedia:最近更改巡查工作，現時肯定就要成為「新頁面巡查」人員，才能擁有核心權限及對應的權利（啟用逐筆巡查功能（非特設的話，默認關閉），則最近更新和監視列表能區分有沒標記巡查的編輯，啟用了新頁面巡查功能（非特設的話，默認開啟），則新頁面能區分有沒標記巡查的編輯，新文件巡查功能也是同新頁面同理）。為了給每筆沒問題的編輯標記沒問題來提醒其他不一定相關的人員「沒問題」，而特意去申請一個為新頁面做巡查的職務或用戶組，我覺得哪裡不對。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 10:05 (UTC)

所以不會這麼做，會進行權限拆分。--Xiplus#Talk 2022年5月25日 (三) 10:06 (UTC)

願聞其詳，希望不是為了彆扭地配合，還要mw開發申請新功能。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 10:08 (UTC)

拆分權限比開發新功能簡單多了，mw開發新功能不行，開發外部工具就可以，是什麼道理？--Xiplus#Talk 2022年5月25日 (三) 10:21 (UTC)

為了使用一個從一開始開發完就被嫌棄的「新」功能，而去彆扭地適配使用，還要靠外部工具去「修正」，還不如不用。因為你提到拆分權限，我無法確定你的想法，我猜想可能是將「patrol」功能拆成適配新頁面、新文件、逐版本編輯的「patrol」，然後重新分配用戶組？所以這意味著是不是還要找mw開發組進行功能適配？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月26日 (四) 02:26 (UTC)

開發新的外部工具就不會被你嫌棄嗎？--Xiplus#Talk 2022年5月27日 (五) 04:33 (UTC)

參考該功能開發初期的討論，我認為好的編輯不需要特意標記（舊en討論也有人提到，假設所有編輯都是可疑的來去標記不是好的wiki風格），壞的編輯直接操作處理則可；壞的編輯處理好後還需要額外的操作來標記之前被破壞的編輯（除了core-rollback似乎能直接標記，但留意到巡查日子似乎沒記錄）；粗略看了commons的巡查日誌，似乎也很少人會做「逐筆編輯標記」的操作，在舊en討論中也提到這個問題。所以既然這個功能從一開發後就被遺棄，單獨啟用了的也似乎是雞肋一樣少用，我不認有啟用的必要。而且這個功能更依賴於「新頁面巡查」用戶組的「patrol」權限，對於只做「最新巡查工作」但不屬於這個用戶組的用戶來說，似乎並不合適。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月27日 (五) 05:59 (UTC)

仍有近百個wiki開啟此功能，單憑en一個wiki不足以證明很難用。--Xiplus#Talk 2022年5月28日 (六) 12:47 (UTC)

不然請您提出改善「重工」問題的具體解決方案。--Xiplus#Talk 2022年5月28日 (六) 12:51 (UTC)

近百wiki啟用功能並不能說明普遍性（反而你需要倒轉數一下有多少wiki是默認關閉的，為什麼這個「逐筆編輯標記」不是普遍使用，反而同源的「新頁面標記」和「新頁面標記」反而是默認啟用的），你應該說明這些wiki是否有大量使用這個功能（也就是經常地使用逐筆標記），否則就會出現某些用戶不會（有功能者）或不能（沒功能者）標記正常編輯或者已處理的編輯而還是存在重複「巡查」的問題。至於「重工」問題，最簡單的處理就是把這個雞肋功能關閉掉，讓一切回歸以前。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月29日 (日) 11:24 (UTC)

以前就有重工問題，您是不是根本不懂哪裡重工。--Xiplus#Talk 2022年5月29日 (日) 11:33 (UTC)

要麼就是「最近巡查」的志願行動和「新頁面巡查」職務性行動因為啟用「逐筆巡查」後的衝突（「逐筆巡查」需要用到「新頁面巡查」的「patrol」功能）；要麼就是你所說的重複檢查需要靠標記來區分，我認為這個需要數據統計，究竟有多少用戶願意去做這樣的標記行為。我認為應該根據已開啟該功能的wiki項目的最近變更數據來統計，如果很少人使用這個功能或者能力（也就是最近編輯中，手工標記的頁面編輯的比例很低甚至幾乎沒有），那就說明這個功能就是雞肋功能，沒必要湊熱鬧來開。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月30日 (一) 02:02 (UTC)

只要有兩個人願意做標記，那麼這兩個人就能夠省下彼此的時間。其他不參與的人一樣會有重工的問題，但其他人要浪費自己的時間我管不著。--Xiplus#Talk 2022年5月30日 (一) 15:23 (UTC)+1 YFdyh000為此+1了。

那只能之後看支持啟用的人有多大的意願去做這種消消樂的活了。（攤手）——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月31日 (二) 04:50 (UTC)

如果只因為「觀感糟糕」，在目前階段，新增CSS/小工具默認禁用、以小工具自選啟用，這樣是否完美？沒有巡查權限是看不到嘆號的，例如我當前只有巡查豁免，看不到嘆號。後續功能得功能開啟才方便測試和有動力開發。其他觀點不贊成。--YFdyh000（留言） 2022年5月24日 (二) 07:55 (UTC)

CSS屏蔽，或者依靠外部行動來標記沒有功能豁免的編輯，我認為不就是掩耳盜鈴？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月24日 (二) 09:53 (UTC)

CSS屏蔽，然後對有巡查權但認為不需要逐筆巡查的用戶，不就跟以前一樣嗎？--YFdyh000（留言） 2022年5月24日 (二) 10:03 (UTC)

話說，這是已經關掉了嗎？現在我已經看不到紅色感嘆號了（除了新建頁面）。另外，我認為其他wiki很少標記，可能更多的原因是具有「巡查標記」功能的用戶組門檻很低，類似於自動確認用戶那樣。如果中文版這邊沒有類似機制，導致的後果就是一片紅色的感嘆號。另外，我對監視列表里的編輯，不會因為有感嘆號標記而去特意查看並「標記為已巡查」，也不會因為沒有感嘆號或已經巡查而就不去看了。最後，這個功能到底我們社群有多大的需求？--百無一用是書生 (☎) 2022年5月24日 (二) 12:35 (UTC)

沒有關閉功能，只是在Mediawiki:Common.css用CSS屏蔽掉了。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 01:08 (UTC)

我認為可以降低逐筆巡查的門檻到擴展確認用戶，以及前期默認不顯示（如上文，通過小工具啟用）。以及通過機器人標註可信用戶，應比巡查豁免多並且進出更靈活。最好能提交批量標記歷史編輯的請求。機器人編輯肯定要默認巡查。對於標記行權爭議，也可再制定規則。--YFdyh000（留言） 2022年5月24日 (二) 13:48 (UTC)

逐筆巡查和新頁面查詢是同源技術，也就是有「patrol」（標記別人編輯已巡查）權限就會看到功能按鈕和進行操作，現階段有的用戶組應該有「新頁面巡查員」和「管理員」。如果基於用戶組的話，可能要給擴展確認用戶添加「autopatrol」（自動標記自己編輯已巡查）權限，但Xiplus認為類似的機制不需要（？），而且前述，兩者同源，如果給了「autopatrol」，連新建頁面都會自動標記巡查，也就是等於有了「巡查豁免」用戶組（該組有這個權限），可能會和「新頁面巡查」的權責有衝突。或者申請開發mw-core功能作為繞過，但需要mw開發組的處理。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 01:08 (UTC)

其實以前在巡查最近更改的時候，就發現有重復巡查的問題，後來我發現Huggle和SWViewer的功能非常的強大，如果說最後這個工具被撤銷，Koala0090君可以試試這兩種程式。--0906_{（回復請Ping我）} 2022年5月24日 (二) 14:01 (UTC)

我的意見就是這個意思，「最近更新巡查」因為定性於非職權性（沒有用戶組，而且逐筆標記似乎過於雞肋，以至於很早（根據配置文件，似乎是en在2005年的討論）被默認禁止了），只需要輔助工具就能解決，如果避免重複巡查的話，完全可以依靠這些工具來實現。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 01:10 (UTC)

請問哪個工具可以檢查一個小時前的編輯？Huggle或SWViewer可以嗎？這些工具都僅能檢查當下新出現的編輯吧。--Xiplus#Talk 2022年5月25日 (三) 03:12 (UTC)

這只是對這些外部工具對過往記錄的回溯能力需求吧？有這個需求的話可以向相關工具開發提出（core-API沒記錯，最近更新列表似乎可以指定回溯的時間？）。如果這些工具長期啟動的話，也可以回溯已經發生過的編輯？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 04:26 (UTC)

MediaWiki本身就有這樣的功能，不理解為何一定要開發新的。--Xiplus#Talk 2022年5月25日 (三) 04:46 (UTC)

你應該問Huggle或SWViewer的開發，這樣外部的最近更新追蹤工具有什麼作用，就是為了給自己標記自己已經「覆核」過的每筆編輯？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 04:58 (UTC)

我認為最近更改巡查對於small wiki或許有些意義，對於更新相當多的wiki完全沒有實用價值--百無一用是書生 (☎) 2022年5月25日 (三) 06:40 (UTC)

另外，實操上，我看到一個好的編輯我可能會標記巡查，但對於壞的編輯我可能直接回退而不會標記為巡查（因為操作太繁瑣）。所以我感覺這個邏輯上有些怪--百無一用是書生 (☎) 2022年5月25日 (三) 06:43 (UTC)

我認為為了提醒別人「好編輯，我巡查過了」或者「壞編輯，我確認過，並處理了」而特意在不斷更新的最近更新裡面啟用這個功能，有點不值的，這在當時這個功能開發出來後就有人提出這個問題，後來開發者初步統計過，的確沒多少人願意做最近更新的巡查標記。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 10:15 (UTC)

如果有必要的話，可以參考當年實現了但又關閉掉這個功能的討論：en:Wikipedia:Village_pump_(news)/Archive_A#Recent changes flags→en:Wikipedia_talk:Checked_edits_brainstorming。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月25日 (三) 06:25 (UTC)

兩天觀察和處理後，對於「撤銷」破壞編輯後的標記情況，我所觀察到：如果使用系統功能rollback的話，是可以將被回退的編輯版本標記巡查（例如這筆：diff=71810208&oldid=71712640），不過在巡查日誌沒有找到該筆版本的巡查記錄，不太確定這個是不是一個bug；如果使用蓋板本的編輯式「回退」（例如：TW的回退、還有系統提供的撤銷），則不會將被回退的編輯版本標記巡查（這筆：diff=71820246&oldid=71789098、diff=71822172&oldid=71822032）。可以將頁面進行監視後然後在監視頁面檢查「嘆號」。所以我認為shizhao的說法可能沒說錯：如果撤銷掉一個破壞，可能不會有人得此返回去將「破壞」的編輯版本進行標記，尤其是用覆蓋版本的編輯來「回退」。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月26日 (四) 02:18 (UTC)

開了功能就多試試吧，沒有必要立即關閉，用CSS把感嘆號的影響處理掉就好，逐筆巡查的按鈕還是有點用的。桐生ここ★[討論] 2022年5月26日 (四) 07:55 (UTC)

或許可以開一個「版本巡查」功能，一旦判定某版本為已巡查版本，就將過去的版本視為已巡查。--Koala0090（留言） 2022年5月28日 (六) 13:14 (UTC)

可以用這個連結，只要僅顯示最新修訂版本+未巡查，就僅會列出最新版本未巡查的頁面。MediaWiki:Gadget-RCPatrol.js則會在歷史中標記最新版本到最近巡查的版本。--Xiplus#Talk 2022年5月28日 (六) 13:37 (UTC)

自動巡查被認為無問題的編輯

前情提要：Wikipedia:機器人/申請/Crystal-bot/3，這是一個會自動巡查已被回退（撤銷）掉的編輯的機器人。@Shizhao認為可以更進一步，將「符合某些條件的用戶」或「ORES打分如何」的編輯直接自動巡查，來讓巡查員更集中於真正需要人工進行巡查的編輯。我的想法是利用ORES的打分來進行判斷。儘管中文項目上精度相比於英文有些不盡人意，但個人認為基本夠用了。

暫擬的規則如下：如果某筆編輯「被認為有危害（damaging）」為真（true）的可能性小於等於0.027（2.7%），則認為這一編輯不需人工巡查，機器人將自動標記為已巡查。按今年的數據來說，此舉可以自動巡查約46%的編輯。希望社群對本提議給出建議。（特別感謝@WhitePhosphorus提供的幫助） Stang^★ 2022年6月8日 (三) 15:09 (UTC)

如何獲取某一筆編輯的ORES打分？以這筆編輯為例，解析請求可知damaging打分為0.014，因此會被自動巡查。 Stang^★ 2022年6月8日 (三) 15:14 (UTC)

 好誒。疑問：1. 機器人或ORES模型是否能及時地自主或輔助糾正「誤判」。2. 如果積壓率極低/清零，建議能自動或適時調高閾值。--YFdyh000（留言） 2022年6月9日 (四) 00:43 (UTC)

理論上ORES會自主學習；有關閾值可以參考下方的FAQ連結（「Where should I set my thresholds for filtering/highlighting」章節）。 Stang^★ 2022年6月9日 (四) 04:34 (UTC)

為何不考慮goodfaith的分數？--百無一用是書生 (☎) 2022年6月9日 (四) 01:54 (UTC)

還有，為何不直接用prediction的真假值，而要用分數做判斷？ORES這一塊我沒仔細看過文檔，不太了解--百無一用是書生 (☎) 2022年6月9日 (四) 01:57 (UTC)

我忘記是從哪裡看到的了，但似乎有說法說這兩個模型的訓練方式不是很一樣；既然goodfaith有更高的recall rate，那可以選用它。我也沒有仔細看過文檔……這個頁面可能有點幫助。 Stang^★ 2022年6月9日 (四) 04:34 (UTC)

或者嚴格一點，damaging為false且goodfaith為true的自動巡查？你那個0.027的條件說實話我不理解為什麼設定這個值？當然，ORES給出的數據我也不是看的很明白[1]。另外，可以參考mw:ORES/Thresholds--百無一用是書生 (☎) 2022年6月9日 (四) 07:05 (UTC)

大致用今年數據統計了一下，排除掉damaging為真或goodfaith為假的編輯，大約88%的編輯都可以自動巡查掉。--百無一用是書生 (☎) 2022年6月9日 (四) 07:58 (UTC)

Re: 「不理解為什麼設定這個值」，mw:ORES/Thresholds#Balancing sensitivity vs. specificity裡面有解釋。--Xiplus#Talk 2022年6月10日 (五) 13:02 (UTC)

@Stang：以全部編輯為分母確實是46%，但您沒有排除自動巡查的編輯，如果以需要巡查的編輯為分母，30天內的數值為33%。--Xiplus#Talk 2022年6月10日 (五) 12:46 (UTC)

沒有「穩定版本能力」的穩定版本。我反而感興趣會有多少具有巡查頁面功能的編輯（例如新頁面巡查或者管理員）會願意手工標記巡查。為了鹽巴而特意弄出一桌子的麵包反而有點本末倒置。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年6月9日 (四) 01:29 (UTC)

成本不高，有一兩個人願意持續做就可以，存廢討論、關注度等很多維護也並沒有很多人堅持。我更關心的是，篩出來的有問題或有爭議的編輯/編者，是否能得到妥善討論和處理，以及標記巡查本身的尺度與責任性。--YFdyh000（留言） 2022年6月9日 (四) 09:34 (UTC)

觀望，因為似乎正在跑手工自動標記測試，而且也留意到將權限分拆的代碼提交（T308153）（PS.如果成功的話，權限組別分配可能會有一些改革調整，例如可能Wikipedia:最近更改巡查可以得到一個職務性的用戶組，Wikipedia:巡查豁免權可能也有所調整）。至於有問題的編輯，如果有需要，本來就應該去提報，和過去的做法無異。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年6月9日 (四) 09:59 (UTC)

客棧方針區升格虛擬內容編輯手冊議案協作告

謹打擾諸位，現虛構編輯指南正處在可能升格階段，是以可能由電遊專案方面活躍編輯加速推進編輯規程化，翻譯、審閱和交換意見可能均有需各有關注涉及虛擬內容之未活躍wikipeoject同好補足之處，已查如歌曲專案之討論版指示為於本版面提起新案，故在此告知，以協調並帶動維基社區更多類似專案協同討論：

該手冊影響範圍可不限於由多個wikiproject可涉及的虛擬事物和跨界產生連續影響關係的系列課題，尤其在本地多個project尚缺少對應專門手冊之下，

總體化之的創作形成、創作內容和創作意義是「可以表述甚麼」並「如何表述這些可以表述的內容」，期待諸位不吝協同參與該總框架手冊的幾大方面，先行給予各自專注方面的智慧和意見，並調動和活躍多方維基人和維基計劃間的互助互利，以補足本地維基參與計劃的系統偏好運作可能遺留的不足之處。謝閱。--約克客（留言） 2022年6月7日 (二) 13:20 (UTC)

悉。( π )題外話：每每觀覽閣下發言，總覺敝人中文造詣尚有諸多不足之處，自愧不如 囧rz……--Rice King 信箱 · 留名．邊緣人_🇹🇼 2022年6月13日 (一) 03:22 (UTC)

（您想多了，情況應該正好是反過來）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月13日 (一) 13:19 (UTC)

Reply tool for mobile editors

Please see Wikipedia:互助客棧/其他/存檔/2022年2月#Reply tool for mobile editors. This will happen on Wednesday. I apologize for the long delay.--Whatamidoing (WMF)（留言） 2022年6月27日 (一) 21:41 (UTC)