維基百科討論:已刪除內容查詢

頁面內容不支援其他語言。
本頁使用了標題或全文手工轉換
維基百科,自由的百科全書

服務名稱[編輯]

當初使用查詢而非請求,主要的考慮是更加親民。現在這個名字已經使用了多年,將名字套用到公開頁面上,令老用戶熟悉。Bluedeck 2017年9月20日 (三) 15:42 (UTC)[回覆]

感覺請求對機制闡述更明確,查詢像是人機自動服務。「已刪內容查詢請求」?--YFdyh000留言2017年9月28日 (四) 23:22 (UTC)[回覆]
嘛,我老覺得請求給人一種成功希望不大的感覺,而這個幾乎一定會成功(一般只有碰到侵權才會查不到),所以就沒叫做請求。Bluedeck 拉斯維加斯槍擊案 2017年10月10日 (二) 07:23 (UTC)[回覆]

否存檔已刪查詢請求的段落[編輯]

是否像一般WP頁面那樣,存檔每個查詢請求的段落?還是像原來一樣,段落用後不存檔直接刪除,僅存檔查詢得到的結果?(不論如何,查詢結果一定是存檔的)

出現這個問題的原因是,AR中的請求基本沒有什麼討論,所以存檔討論像是一種浪費。而且之前不存檔運行的也挺好。所以我覺得可以不存檔留言。雖然存檔也沒有壞處。Bluedeck 2017年10月12日 (四) 21:02 (UTC)[回覆]

標題[編輯]

標題應該使用條目名稱,而不是「已刪除內容查詢」。--M.Chan 2017年10月17日 (二) 07:57 (UTC)[回覆]

謝謝,這個是舊系統沿用造成的問題,已經更新了。Bluedeck 2017年10月18日 (三) 17:55 (UTC)[回覆]

刪除內容查詢公開化[編輯]

已刪除內容作為一個公開服務是我從一開始就有的設想。WP:AR是最開始創建的頁面。但是當時社區沒有同意我在那邊運作,所以我把這個服務放在自己的用戶頁進行。那麼現在這個功能已經越來越完善,並有着多項的配套設施,不知道大家的想法改變了沒有。

  • 關於已刪查詢公開化,主要的問題是這樣的。
    1. 已刪查詢本身不適合作為一個大量常用的功能提供。維基百科的數據結構是自增id表,因此查詢時所有數據都複製了兩份,效率很低。也許伺服器處理期間我們不需要考慮,但是大量查詢的磁碟成本是顯著的。因此已刪查詢還是劣於頁面恢復,只能作為臨時解決方案。
    2. 已刪查詢模糊刪除和不刪除的界限。當然這就是已刪查詢的作用所在。那麼這樣究竟好不好,就是另一個問題。
    3. 誤操作(忘記flood)容易沖刷最近更改。我在查詢的時候曾多次沖刷RC,白磷肯定深有體會。
    4. 懶惰的 Bluedeck 至今還在採用 sync XHR 作為插件通信機制,導致管理員端插件在查詢時會凍住查詢用的tab。
  • 公開化對已刪查詢的好處
    1. 提高知名度,使更多人知道和使用。
    2. 目前已經提供任何管理員都能使用的管理員端查詢工具。
    3. 用戶用的已刪除查詢插件可以經過非常簡單的修改就轉而po到公開已刪查詢頁面上。
    4. 雖然目前和可預見的將來,Bluedeck 能夠輕易處理所有請求,但是將這項服務轉變為不依賴某一個管理員的活躍度的服務總是一件好事。

那麼就是這樣,請問大家怎麼看。Bluedeck 2017年9月18日 (一) 13:46 (UTC)[回覆]

現有的存廢覆核請求已提供最後版本索取功能,是否有必要另闢頁面處理是項請求?——Aotfs2013 留於 2017年9月18日 (一) 14:17 (UTC)[回覆]

跟已刪查詢相比那個功能和DRV的程序混雜在一起,又不能提供完整歷史,也沒有插件之類的,並不是一個質量的服務。因此,我的想法是,DRV專心DRV,已刪查詢服務轉到AR,讓專業的來。Bluedeck 2017年9月18日 (一) 16:06 (UTC)[回覆]
同意。DRV的重心,在於判斷AFD有否流程上的失誤、或有新的重要證據出現,以致AFD結果需重新考慮。這和AR的目的顯然不一致。"已刪查詢模糊刪除和不刪除的界限"的問題不難解決-規定NOINDEX、查詢後一段可以CSD就可以解決。--Temp3600留言2017年9月18日 (一) 18:50 (UTC)[回覆]
其實我覺得弄個Deletionpedia放着更好--百無一用是書生 () 2017年9月19日 (二) 02:11 (UTC)[回覆]
  • 條目被刪除不等於全無所用,找回被刪頁面不但可作為改善條目的基礎,也具有研究用途,可了解條目先前被刪除的原因,有助於方針指引的修訂與執行。目前DRV只發送源碼,無法查閱條目的編輯歷史及過往編輯版本,而且英文版提供刪除頁面查閱服務未見出現亂子,在本地提供有助監察使用情況,站外服務則難以本地控制,實無依賴站外服務之必要。--Thomas.Lu留言2017年9月19日 (二) 03:52 (UTC)[回覆]
中文版的Deletionpedia好像見過兩個,但好像之後像是雷聲大,雨聲小。——路過圍觀的Sakamotosan 2017年9月19日 (二) 04:02 (UTC)[回覆]
其一[1] 不過已經沒更新了,如果要搞一個刪除wiki則除了侵權和人身攻擊不收其它都收。--Zest 2017年9月19日 (二) 07:42 (UTC)[回覆]
labs上可以放一個?--百無一用是書生 () 2017年9月19日 (二) 09:33 (UTC)[回覆]
(+)支持,因關注度刪掉連最後版本都無法看見,深受其害。--owennson聊天室獎座櫃2017年9月19日 (二) 11:43 (UTC)[回覆]
我心目中的理想情況是將已刪查詢wikitext和查詢時間點parse出來的HTML存到獨立的伺服器去,目的是可以設定一個有效期限(比如180日),這樣就可以放心的大量查詢,而不用考慮磁碟問題。Bluedeck 2017年9月19日 (二) 11:51 (UTC)[回覆]
[2]wiki已經初步架好,有人感興趣嗎?--百無一用是書生 () 2017年9月20日 (三) 14:10 (UTC)[回覆]
站外查詢儲存需要儲存html而不是wikitext,所以維基系統反而不適合儲存維基查詢結果。這個原因是,wikitext會實時展開模版,所以要麼在本地維基查詢然後實時展開本地模版;要麼儲存查詢請求當時渲染好的HTML,呈現時直接呈現成品HTML。不過如果不在乎這個問題,shizhao的deletepedia是更優的選項。Bluedeck 2017年9月20日 (三) 15:27 (UTC)[回覆]
deletewiki是個不錯的想法。之前我就有想過把所有掛上CSD、進入AFD的條目自動轉存到外部的維基上。單純存儲維基代碼,即使無法正常顯示模板,但也方便大致了解條目內容以及再利用這些文字。--Tiger留言2017年9月20日 (三) 15:47 (UTC)[回覆]
問題不止這些吧,例如收錄規則:是自動收錄還是手工提交收錄,收錄標準是什麼(除侵權和G11以外?);管理規則:誰能當管理員;編輯規則:開不開放普通編輯。即使是單純收錄解釋後的頁面,也需要先考慮如何制定這些東西。——路過圍觀的Sakamotosan 2017年9月21日 (四) 01:02 (UTC)[回覆]
根據我對其他幾個Deletionpedia的初步觀察,都是自動收錄為主,手工為輔,存檔性質的。收錄標準大致是除了侵權、人身攻擊和涉及私隱之外被刪除的頁面(有些似乎只是收條目),另外也允許其他人提刪已收錄頁面(因為侵權、人身攻擊和私隱,也可能包括作者或條目相關利益方的訴求,畢竟介紹自家的東西放在Deletionpedia算不上好)。大部分Deletionpedia是不開放編輯的(可以向管理者請求賬號和權限),少數開放編輯,畢竟只是存檔,編輯也就是一些修復性工作。另外,toollabs理論上不允許架設的mediawiki搞開放編輯。要做的話,學習他人經驗很重要--百無一用是書生 () 2017年9月21日 (四) 02:18 (UTC)[回覆]

余試用之,自覺該功能甚佳。自己還是新手的時候,犯了一些錯誤,導致條目被因為關注度和無來源提刪掉。現在看來,錯誤極為幼稚。有時候這種功能就是一種警示,給後來者看看這個頁面是因為什麼刪掉了,以提供重建時的借鑑。(+)支持。--雲間守望 · 留言💬 2017年9月29日 (五) 15:00 (UTC)[回覆]


似乎在公示前收不到更多意見了,那麼公示14日,如果沒有人反對,則着手修繕和開放WP:ARBluedeck 2017年9月25日 (一) 18:13 (UTC)[回覆]

幾天測試下來,wmflabs的性能實在太差,導入個頁面就超時的一塌糊塗。如果要架個wiki存檔,看來還是要另找地方才行,或者弄個基金會的Cloud VPS可能會好點--百無一用是書生 () 2017年9月28日 (四) 07:10 (UTC)[回覆]
如果有非管理員以非公開的方式存儲了被刪條目,是否可以協助處理「已刪內容查詢」請求?--Tiger留言2017年9月29日 (五) 23:24 (UTC)[回覆]
當然可以,這個服務的目的就是搭建一個不正式、非常容易操作和使用的溝通平台,任何人的幫助都是歡迎的。甚至user:bluedecklibrary中存儲的內容也可以用於這個目的。Bluedeck 2017年10月1日 (日) 03:24 (UTC)[回覆]
公示期間還剩7日。Bluedeck 2017年10月2日 (一) 22:52 (UTC)[回覆]
公示期間還剩2日。Bluedeck 拉斯維加斯槍擊案 2017年10月7日 (六) 20:14 (UTC)[回覆]

WP:AR已經重新開放,新請求在彼處受理。接下來的一個月裏,介面將稍做改動,user talk:bluedeck 的已刪除內容查詢將逐漸關閉,插件所po請求也會轉而投遞至WP:AR,DRV等其他頁面的措辭也會相應修改。謝謝大家的討論。Bluedeck 拉斯維加斯槍擊案 2017年10月10日 (二) 02:00 (UTC)[回覆]

WP:RFUD似乎重定向到Wikipedia:存廢覆核請求會比較好?--A2093064#Talk 2017年10月10日 (二) 07:11 (UTC)[回覆]
似乎是的 Bluedeck 拉斯維加斯槍擊案 2017年10月11日 (三) 23:10 (UTC)[回覆]
哦,不是的,RFUD之所以重定向給AR,是因為英維就是如此做的。Bluedeck 2017年10月12日 (四) 16:41 (UTC)[回覆]
這是因為英文版的RFUD有恢復頁面的功能(例如英文維基速刪G13的恢復,在中文版可以想成請求恢復被CSD O1或G10刪除的頁面),但在中文維基這應該到WP:DRV進行,現在WP:AR應該是沒有接受恢復頁面請求。--A2093064#Talk 2017年10月13日 (五) 04:35 (UTC)[回覆]
英文RFUD:Please note that this page is NOT for challenging the outcome of deletion discussions or to address the pending deletion of any page。所以RFUD和AR的作用是一樣的,只不過RFUD把頁面直接放到草稿,而不使用插件整個頁面複製一遍(其實是更好的做法)。在實際處理AR的時候,AR也曾直接恢復草稿頁面。Bluedeck 2017年10月18日 (三) 17:52 (UTC)[回覆]
  • 看過WP:AR有個疑問:已刪除的內容仍然需要署名嗎?在AR可否僅提供最後版本?是否必須像Bluedeck先前在自己的討論頁提供的信息一樣,給出編輯時分、用戶、頁面大小、版本號、編輯摘要?--Tiger留言2017年10月10日 (二) 12:27 (UTC)[回覆]
如果使用藍桌插件,那麼就自動生成這個包含完整信息的列表。手動操作過於繁瑣,不可能把整個歷史存檔起來,因此,推薦使用該插件(第四個)。然而,如果不想使用插件,執行查詢的管理員想給出某個特定版本當然可以。比如,可能某個頁面所有版本的差別都不大,而且主要作用是重寫條目的話,那就只貼出內容最豐富的版本就好。如果用戶進一步要求,再給出更多版本。Bluedeck 拉斯維加斯槍擊案 2017年10月11日 (三) 23:07 (UTC)[回覆]
所有被刪除內容直接通過Data Services查詢數據庫就好了:
MariaDB [zhwiki_p]> SELECT ar_id,ar_title,ar_user,ar_timestamp from archive where ar_title = "研鼎崧圖";
+---------+--------------+---------+----------------+
| ar_id   | ar_title     | ar_user | ar_timestamp   |
+---------+--------------+---------+----------------+
| 2984638 | 研鼎崧圖     | 2208492 | 20151225073237 |
| 2984639 | 研鼎崧圖     |  687728 | 20151225105745 |
| 2984640 | 研鼎崧圖     |   90660 | 20171019094401 |
| 2984641 | 研鼎崧圖     |   90660 | 20171019094558 |
+---------+--------------+---------+----------------+
4 rows in set (1.32 sec)

--百無一用是書生 () 2017年10月27日 (五) 02:18 (UTC)[回覆]

Wikipedia:已刪除內容查詢是否允許查詢明顯的人身攻擊內容?[編輯]


如題。--E8×E81322018年2月21日 (三) 04:01 (UTC)[回覆]

「無爭議頁面直接復原」節[編輯]

請加入有關O7的附註。Sæn中動員令:為西雅圖橋樑列表消綠 2018年7月13日 (五) 12:19 (UTC)[回覆]

謝謝建議,長期以來沒看到,現在已經完成了。Bluedeck 2018年9月26日 (三) 17:36 (UTC)[回覆]

查詢用戶自己刪除的內容是否合適呢?[編輯]

是否可以查詢Wikipedia:已刪除內容查詢#User:DGideas/oops類似這種呢?如果使用者有不再想讓大家看到的內容,我們是否應該讓使用者有權拒絕將這個內容公之於眾呢?我覺得這不是應該由我一個人決定的問題。我徵求一下社區的意見。Bluedeck 2018年9月11日 (二) 21:27 (UTC)[回覆]


那麼就這個討論而言,得出結論是需要使用者本人同意,或者有些重要的理由(比如內容是有價值的條目等)可以查詢作為結果,這樣可以嗎?Bluedeck 2018年10月1日 (一) 22:43 (UTC)[回覆]

其實管理員認可就可以,私下查詢也沒人知道不是嗎。--YFdyh000留言2018年10月4日 (四) 03:36 (UTC)[回覆]
因為不想讓這件事情就按照執行的管理員的心情來辦,因此才希望弄個清楚的。如果這樣的話私下查詢應該也遵守這樣的規則了。Bluedeck 2018年10月5日 (五) 15:49 (UTC)[回覆]
( ✓ )同意-- Sunny00217 2018年10月8日 (一) 13:11 (UTC)[回覆]

已刪除查詢改為移動?[編輯]

既然這樣,那好吧,我還是按照原樣處理。Bluedeck 2018年10月13日 (六) 18:51 (UTC)[回覆]
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

對於大的頁面,這個功能佔用數十MB磁盤。舉一個最近遇到的比較極端的例子,一個頁面500+版本,每個版本50+kb,查詢一次約消耗25MB磁碟。加上數據庫結構文件可能比25MB還大一點。

小的頁面沒什麼問題,但是我想當遇到100個以上版本的已刪除,能不能直接恢復到WP:已刪除內容查詢/查詢中去,不用特別的複製一份呢?反正效果其實不差。

(其實小的頁面也可以直接恢復,移動到上述位置)

雖然說不要在意性能,但是既然效果完全一樣,那麼是否可以通過這個方法節約一點磁盤呢?之前曾有人跟我說過這樣的話刪除不是跟沒刪一樣了嗎。但是英文版就是這樣,有想要的會恢復。而且目前的查詢和恢復也相差無幾了。Bluedeck 2018年10月8日 (一) 23:52 (UTC)[回覆]


本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

WP:AR的積壓[編輯]

WP:AR里有約20個請求的積壓. 有管理員會去處理嗎 囧rz…… --Yining Chen留言|簽名2021年7月19日 (一) 12:50 (UTC)[回覆]

有個可行的方案,就是把Brror對話頁 | 使用者貢獻)閣下送到rfa,不知道您接受嗎?--Papayatrash留言2021年7月19日 (一) 12:59 (UTC)[回覆]
這個似乎非管理員也能做?可以考慮成立一個組織(類似WP:485)去做這個事情。不知道可不可行。--Lightyears GBAW 2021年7月19日 (一) 13:44 (UTC)[回覆]
有些頁面可以通過藍桌圖書館等方式查詢,但有些查不到,需要管理員;Brror閣下應該是能查的都查了。我建議有一定經驗的維基人提AR請求時,先在藍桌圖書館、已刪百科等地方查詢,查不到再提報;並在提報時標註「請管理員查詢」或直接寫一個sysop。至於RFA,要看Brror閣下是否接受。 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年7月20日 (二) 01:54 (UTC)[回覆]
@30000lightyears:問題是現在能查看歷史的人必須有反刪除undelete權限,該權限基本上不太可能下放的(除非有非常合理的原因給基金會願意做個權限如顯示已刪除的歷史viewdeleted)-- Sunny00217  2021年7月21日 (三) 11:42 (UTC)[回覆]
正在詢問Brror對話頁 | 使用者貢獻)。--Yining Chen留言|簽名2021年7月22日 (四) 03:42 (UTC)[回覆]
使用者已接受。--Lightyears GBAW 2021年7月22日 (四) 05:30 (UTC)[回覆]
@Yining Chen:Brror君已經接受提名,您可以提名了。--Lightyears GBAW 2021年7月22日 (四) 05:34 (UTC)[回覆]
已完成。--Yining Chen留言|簽名2021年7月23日 (五) 02:04 (UTC)[回覆]

收緊AR使用限制[編輯]

明顯不具百科性或是明顯屬於擾亂性內容的不應該被查詢。現行條文不會查詢被修訂版本刪除的內容,嚴格來說其實已經涵蓋。AR本意應該是讓想重新編輯的人找到原本內容,好使其不用從零開始。如果相關內容明顯不具百科性或是明顯屬於擾亂性內容我不認為查詢這些內容有益於建設百科全書。副抄最常處理AR的U:Jonathan5566參與討論-某人 2021年10月16日 (六) 02:09 (UTC)[回覆]

部分AR無需管理員操作,對它們加以限制意義不大。--安憶Talk 2021年10月16日 (六) 02:26 (UTC)[回覆]
多次違反限制就封鎖AR頁編輯不就行了?無需管理員操作不是因此就完全不設限的理由-某人 2021年10月16日 (六) 02:32 (UTC)[回覆]
反對提案。一來查詢明顯不具百科性或明顯屬於擾亂性的內容可能是出於研究LTA行為的目的,二來一般用戶通常不太可能得知自己查詢的內容是屬於明顯不具百科性或明顯屬於擾亂性的內容的情形。就後者而言,我認為提案本身就是在假定惡意Sanmosa WÖRK 2021年10月16日 (六) 03:40 (UTC)[回覆]
@Sanmosa那麼我舉個更明確的例子,真有疑慮的話可以放寬為「如有合理理由可以豁免」(例如研究lta行為)-某人 2021年10月16日 (六) 03:57 (UTC)[回覆]

完全重寫header[編輯]

現行條文

操作幫助:請直接點「提交新請求」,過程簡單,處理迅速。對於絕大多數條目,不需要理由,想看即可查詢。處理完成後會通知您查看。

無爭議頁面直接復原:如果您是自己O1或者G10刪除了您自己的頁面,我們將不查詢而直接恢復這個頁面(除非您特別要求僅查詢)。類似的,僅因為無人編輯的草稿(O7)和無人使用的模板等頁面也將直接被恢復。

注意

  1. 除上述情況外,本條目找回計劃不能用於直接恢復條目,而是找回頁面的歷史版本,以避免您沒儲存的工作付諸東流。頁面被刪除都有一定的原因,故此找回的內容也許不適合直接放回被刪除前的地方去——請在這麼做之前將內容修改得符合我們的各項方針。如果您需要對刪除本身進行複核,請前往存廢覆核請求
  2. 如果你要查詢的頁面是別人O1的,請向請求刪除的那個人索要,而不是在這裏提出查詢。
  3. 如果你要查詢的是模板,請給出理由,否則查詢請求會被拒絕。

使用限制:根據維基百科基本原則,侵權文字不能找回,被刪除修訂版本的頁面也不能。但是對於侵權頁面,我們可以幫您找回侵權來源和歷史版本列表。您可以從侵權來源處下載相應文字。

提議條文

操作幫助:請點「提交新請求」並且填寫查詢原因。請注意不填寫理由將會被直接拒絕。

使用限制

  1. 如尋求恢復自己O1或者G10刪除了的頁面,或是沒有人編輯而O7的草稿,請移玉步至存廢覆核請求,此處僅處理頁面歷史查詢。
    • 但如果你要查詢的頁面是別人O1的,請向請求刪除的那個人索要,而不是在這裏或存廢覆核請求提出查詢。
  2. 此處不能查詢被刪除修訂版本的頁面。
  3. 此處不能查詢侵權頁面,但我們可以幫您找回侵權來源。您可以從侵權來源處下載相應文字。
  4. 如無合理理由,此處不能查詢G1,G3或G12的內容。如你認為相關刪除不合理請移玉步至存廢覆核請求

注意

本計劃不能用於直接恢復條目,而是找回頁面的歷史版本,以避免您沒儲存的工作付諸東流。頁面被刪除都有一定的原因,故此找回的內容也許不適合直接放回被刪除前的地方去。請在這麼做之前將內容修改得符合我們的各項方針。如果您需要對刪除本身進行複核,請前往存廢覆核請求

Tldr幾個主要修改:

  1. 明文規範申請應有合理理由。Xiplus提到基於法律原因已刪內容僅允許管理員可以瀏覽。繞過這個限制必須檢查有關請求是否合理。
  2. 明文規範無爭議頁面還原應前往存廢覆核請求,這種頁面應還原整個頁面歷史。由於AR非管理員亦可處理,這種請求應前往DRV。
  3. 規範G3或G12內容如無合理理由不可查詢,見上討論。
另外,我不反對O7等轉至存廢覆核處理,但請不要超前部屬。--拒食木瓜 2021年10月16日 (六) 11:59 (UTC)[回覆]
一案兩提我直接關掉一處我不認為有問題-某人 2021年10月16日 (六) 12:09 (UTC)[回覆]
@AINH:雖然說我沒expect具體提案會轉介G10、O1與O7到DRV,但我認可這樣改。有次我在AR請求恢復自己的子頁面,過了好幾天都沒人處理,結果我放到DRV後才有人在DRV看到並處理了,因此就效率而言轉介G10、O1與O7到DRV是好事。不過有一點想提的是「除非您特別要求僅查詢」這部分,我認為提議條文「使用限制」第一條可增加用戶特別要求僅查詢經G10、O1與O7刪除的頁面的情形,這時候除非查詢的對象是他人的用戶頁(或子頁面),否則一概以查詢一般頁面的程序處理。Sanmosa WÖRK 2021年10月18日 (一) 13:44 (UTC)[回覆]
不太明白你的建議是什麼-某人 2021年10月18日 (一) 22:42 (UTC)[回覆]
@AINH:「如果您是自己O1或者G10刪除了您自己的頁面,或是沒有人編輯而O7的草稿,我們將不查詢而直接恢復頁面。但這些類別請移玉步至存廢覆核請求,此處不受理。」改為「如尋求恢復自己O1或者G10刪除了的頁面,或是沒有人編輯而O7的草稿,請移玉步至存廢覆核請求,此處僅處理頁面歷史查詢。」Sanmosa WÖRK 2021年10月20日 (三) 01:50 (UTC)[回覆]
  • 未見明顯反對,開始公示. CC@AnYiLinSanmosaJonathan5566:-某人 2021年10月21日 (四) 00:31 (UTC)[回覆]
    • 我來明顯(-)反對一下哈。為了說明我的觀點,我先提出一個問題,沒有理由拒絕查詢是吧,那假如說有三個人來查詢三個「明顯擾亂頁面」,分別給出的理由是1)「想看」,2)想親自確認內容是否符合刪除標準,3)可能會有有用的內容但是我看不見所以想查詢。請問這三個理由中有哪些是有效理由呢?如果有無效的理由,為什麼無效?Bluedeck 2021年10月21日 (四) 05:44 (UTC)[回覆]
      @Bluedeck:一無效,與編輯維基百科無關。二應算為有效。三應該更詳盡地問其查看內容是否有用的目的是什麼,如果他的目的是重寫條目應算為有效,但處理人提供前應先看內容是否有用,如果全文胡言亂語應拒絕並寫明內容無用。而且「沒有理由拒絕查詢」不是我提的,這是U:Xiplus說的。那麼你的反對原因是什麼?-某人 2021年10月21日 (四) 05:52 (UTC)[回覆]
      這個問題無法回答,判斷是否接受查詢還要考慮已刪內容的性質,靈活採取不一樣的處理措施,例如G12內容無法在維基上提供複本,但必要時可以考慮私下郵件提供。視不同的情況可以採取不同的措施:完全拒絕 - 透露內容性質 - 私下提供內容 - 提供最新版本內容 - 提供特定數個重要版本內容 - 提供完整版本內容 - 直接恢復完整頁面。--Xiplus#Talk 2021年10月21日 (四) 06:03 (UTC)[回覆]
    未見對於"一般用戶通常不太可能得知自己查詢的內容是屬於明顯不具百科性或明顯屬於擾亂性的內容的情形。就後者而言,我認為提案本身就是在假定惡意。"的有效回答。--拒食木瓜 2021年10月21日 (四) 07:32 (UTC)[回覆]
    條文已經沒用「明顯不具百科性或明顯屬於擾亂性」之類的主觀判斷,已經收窄至「G1,G3或G12」的明確標準-某人 2021年10月21日 (四) 07:38 (UTC)[回覆]
我不喜歡上面的提案內容。--Xiplus#Talk 2021年10月22日 (五) 03:01 (UTC)[回覆]
現行條文

提議條文

操作幫助:請點「提交新請求」並且填寫合理的查詢原因,管理員會根據查詢原因決定是否接受查詢。

使用限制

  1. 本計劃不能用於直接還原頁面,而是找回頁面的歷史版本,以避免您沒儲存的工作付諸東流。頁面被刪除都有一定的原因,故此找回的內容也許不適合直接放回被刪除前的地方去。請在這麼做之前將內容修改得符合我們的各項方針。
  2. 如果您想要還原頁面的完整歷史(包括但不限於認為相關刪除不合理、想要恢復您自己提刪的O1和G10或被O7刪除的草稿),請前往存廢覆核請求
  3. 如果查詢的相關內容將再次符合刪除準則(包括但不限於侵權頁面、已被版本刪除、多數的G3和G12頁面),管理員將不會在站內提供相關內容。
    根據您的查詢理由,如有必要,管理員可能會以郵件私下提供、透露內容性質但不提供實際內容、拒絕請求等方式處理。
    侵權頁面可能會以提供侵權來源方式處理。
--Xiplus#Talk 2021年10月22日 (五) 03:02 (UTC)[回覆]
(+)傾向支持看起來不錯。--SD hehua會客室/歡迎簽到2021年10月22日 (五) 10:10 (UTC)[回覆]
我主要是因為看到「轉介G10、O1與O7到DRV」才有特別希望同意的理由,只要提案做到「轉介G10、O1與O7到DRV」我都支持。Sanmosa WÖRK 2021年10月22日 (五) 10:14 (UTC)[回覆]
做了微調。--Xiplus#Talk 2021年10月26日 (二) 01:44 (UTC)[回覆]

討論[編輯]

(...) 吐槽:不能因為AR積壓就收緊使用AR的範圍啊 --Yining Chen留言|簽名2021年11月4日 (四) 13:04 (UTC)[回覆]

WP:AR積壓[編輯]

如題,Wikipedia:已刪除內容查詢,希望有人出來處理--John123521留言-貢獻 2022年2月14日 (一) 10:11 (UTC)[回覆]

如果有需求可以去申請的回退員看過濾器日誌,會比較實用。其他積壓需要管理員處理,但看起來無望。--拒食木瓜 2022年2月20日 (日) 03:00 (UTC)[回覆]
Xiplus清了。--Ghren🐦🕓 2022年2月20日 (日) 08:22 (UTC)[回覆]
希望更多管理員能投入到此類事務上面來。—— Eric Liu 創造は生命(留言留名學生會 2022年2月20日 (日) 11:36 (UTC)[回覆]