維基百科討論:已刪除內容查詢
服務名稱
[編輯]當初使用查詢而非請求,主要的考慮是更加親民。現在這個名字已經使用了多年,將名字套用到公開頁面上,令老用戶熟悉。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)
- 確實。而且編輯記錄都留着,實在要查也不擔心記錄丟失。--Tiger(留言) 2017年10月15日 (日) 07:18 (UTC)
- 其實翻歷史也很麻煩......存檔更好吧--PatrollerAAAA(討論|留名) 2017年10月15日 (日) 07:34 (UTC)
- 如果要翻查查詢請求本身,確實翻查歷史比較麻煩。可以誰會去查這個呢,既然Wikipedia:已刪除內容查詢/查詢裡面列出了所有查詢記錄,直接查這個更快更清楚嘛。Bluedeck 2017年10月15日 (日) 18:52 (UTC)
- 不如存檔至查詢結果的討論頁吧。--M.Chan 2017年10月17日 (二) 02:48 (UTC)
- 那豈不是更沒有用了:/ Bluedeck 2017年10月17日 (二) 02:50 (UTC)
- 有時會說兩句:「話說回來這條目不應快速刪除呀。」我會好奇看看。--M.Chan 2017年10月17日 (二) 07:54 (UTC)
- 那好吧,既然有一點用,那就存檔好了。Bluedeck 2017年10月18日 (三) 17:54 (UTC)
- 有時會說兩句:「話說回來這條目不應快速刪除呀。」我會好奇看看。--M.Chan 2017年10月17日 (二) 07:54 (UTC)
- 那豈不是更沒有用了:/ Bluedeck 2017年10月17日 (二) 02:50 (UTC)
- 不如存檔至查詢結果的討論頁吧。--M.Chan 2017年10月17日 (二) 02:48 (UTC)
- 如果要翻查查詢請求本身,確實翻查歷史比較麻煩。可以誰會去查這個呢,既然Wikipedia:已刪除內容查詢/查詢裡面列出了所有查詢記錄,直接查這個更快更清楚嘛。Bluedeck 2017年10月15日 (日) 18:52 (UTC)
標題
[編輯]標題應該使用條目名稱,而不是「已刪除內容查詢」。--M.Chan 2017年10月17日 (二) 07:57 (UTC)
- 謝謝,這個是舊系統沿用造成的問題,已經更新了。Bluedeck 2017年10月18日 (三) 17:55 (UTC)
已刪除內容查詢公開化
[編輯]已刪除內容作為一個公開服務是我從一開始就有的設想。WP:AR是最開始創建的頁面。但是當時社區沒有同意我在那邊運作,所以我把這個服務放在自己的用戶頁進行。那麼現在這個功能已經越來越完善,並有着多項的配套設施,不知道大家的想法改變了沒有。
- 關於已刪查詢公開化,主要的問題是這樣的。
- 已刪查詢本身不適合作為一個大量常用的功能提供。維基百科的數據結構是自增id表,因此查詢時所有數據都複製了兩份,效率很低。也許服務器處理期間我們不需要考慮,但是大量查詢的磁碟成本是顯著的。因此已刪查詢還是劣於頁面恢復,只能作為臨時解決方案。
- 已刪查詢模糊刪除和不刪除的界限。當然這就是已刪查詢的作用所在。那麼這樣究竟好不好,就是另一個問題。
- 誤操作(忘記flood)容易沖刷最近更改。我在查詢的時候曾多次沖刷RC,白磷肯定深有體會。
- 懶惰的 Bluedeck 至今還在採用 sync XHR 作為插件通信機制,導致管理員端插件在查詢時會凍住查詢用的tab。
- 公開化對已刪查詢的好處
- 提高知名度,使更多人知道和使用。
- 目前已經提供任何管理員都能使用的管理員端查詢工具。
- 用戶用的已刪除查詢插件可以經過非常簡單的修改就轉而po到公開已刪查詢頁面上。
- 雖然目前和可預見的將來,Bluedeck 能夠輕易處理所有請求,但是將這項服務轉變為不依賴某一個管理員的活躍度的服務總是一件好事。
那麼就是這樣,請問大家怎麼看。Bluedeck 2017年9月18日 (一) 13:46 (UTC)
- (+)支持,用過數次了,感覺還是搬出去比較好。--安迪安迪安迪安倍~~(颱風吹襲|留名記錄) 2017年9月18日 (一) 14:01 (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)
- 中文版的Deletionpedia好像見過兩個,但好像之後像是雷聲大,雨聲小。——路過圍觀的Sakamotosan 2017年9月19日 (二) 04:02 (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)
- [2]wiki已經初步架好,有人感興趣嗎?--百無一用是書生 (☎) 2017年9月20日 (三) 14:10 (UTC)
- 根據我對其他幾個Deletionpedia的初步觀察,都是自動收錄為主,手工為輔,存檔性質的。收錄標準大致是除了侵權、人身攻擊和涉及隱私之外被刪除的頁面(有些似乎只是收條目),另外也允許其他人提刪已收錄頁面(因為侵權、人身攻擊和隱私,也可能包括作者或條目相關利益方的訴求,畢竟介紹自家的東西放在Deletionpedia算不上好)。大部分Deletionpedia是不開放編輯的(可以向管理者請求賬號和權限),少數開放編輯,畢竟只是存檔,編輯也就是一些修復性工作。另外,toollabs理論上不允許架設的mediawiki搞開放編輯。要做的話,學習他人經驗很重要--百無一用是書生 (☎) 2017年9月21日 (四) 02:18 (UTC)
余試用之,自覺該功能甚佳。自己還是新手的時候,犯了一些錯誤,導致條目被因為關注度和無來源提刪掉。現在看來,錯誤極為幼稚。有時候這種功能就是一種警示,給後來者看看這個頁面是因為什麼刪掉了,以提供重建時的借鑑。(+)支持。--雲間守望 · 留言💬 2017年9月29日 (五) 15:00 (UTC)
似乎在公示前收不到更多意見了,那麼公示14日,如果沒有人反對,則着手修繕和開放WP:AR。Bluedeck 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)
- 公示期間還剩7日。Bluedeck 2017年10月2日 (一) 22:52 (UTC)
- 當然可以,這個服務的目的就是搭建一個不正式、非常容易操作和使用的溝通平台,任何人的幫助都是歡迎的。甚至user:bluedecklibrary中存儲的內容也可以用於這個目的。Bluedeck 2017年10月1日 (日) 03:24 (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)
- 這是因為英文版的RFUD有恢復頁面的功能(例如英文維基速刪G13的恢復,在中文版可以想成請求恢復被CSD O1或G10刪除的頁面),但在中文維基這應該到WP:DRV進行,現在WP:AR應該是沒有接受恢復頁面請求。--A2093064#Talk 2017年10月13日 (五) 04:35 (UTC)
- 哦,不是的,RFUD之所以重定向給AR,是因為英維就是如此做的。Bluedeck 2017年10月12日 (四) 16:41 (UTC)
- 似乎是的 Bluedeck 拉斯維加斯槍擊案 2017年10月11日 (三) 23:10 (UTC)
- 看過WP:AR有個疑問:已刪除的內容仍然需要署名嗎?在AR可否僅提供最後版本?是否必須像Bluedeck先前在自己的討論頁提供的信息一樣,給出編輯時分、用戶、頁面大小、版本號、編輯摘要?--Tiger(留言) 2017年10月10日 (二) 12:27 (UTC)
- 如果使用藍桌插件,那麼就自動生成這個包含完整信息的列表。手動操作過於繁瑣,不可能把整個歷史存檔起來,因此,推薦使用該插件(第四個)。然而,如果不想使用插件,執行查詢的管理員想給出某個特定版本當然可以。比如,可能某個頁面所有版本的差別都不大,而且主要作用是重寫條目的話,那就只貼出內容最豐富的版本就好。如果用戶進一步要求,再給出更多版本。Bluedeck 拉斯維加斯槍擊案 2017年10月11日 (三) 23:07 (UTC)
- 查詢已刪除的「其他用戶的User頁或其子頁面」是否需要限制?--Mewaqua(留言) 2017年10月13日 (五) 02:47 (UTC)
- (+)支持上面的意見。--【和平至上】💬📝 2017年10月13日 (五) 14:41 (UTC)
- 個人認為等同對待,因為這是CC協議賦予的權利。不過可以理解用戶不想被看自己的內容的情況,所以這個情況可以討論。Bluedeck 2017年10月16日 (一) 07:31 (UTC)
- (+)支持上面的意見。--【和平至上】💬📝 2017年10月13日 (五) 14:41 (UTC)
- (+)支持 Why not? : ) --It's gonna be awesome!✎Talk♬ 2017年10月16日 (一) 08:13 (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×E8(132) 2018年2月21日 (三) 04:01 (UTC)
- 不允許。--安迪4(討論|留名) 2018年2月21日 (三) 04:09 (UTC)
- 現在有很多攻擊其他用戶的頁面被查詢後貼了出來。--E8×E8(724) 2018年2月21日 (三) 04:17 (UTC)
- @Bluedeck:請看一下你這次查詢的全部頁面,一堆屬於人身攻擊的,請求處理。--Zest 2018年2月21日 (三) 05:24 (UTC)
- 我認為是可以的,之前也查詢過類似「fuck」這樣的頁面。我在這裡的標準同於RRD2一致,即「破壞、辱罵、人身攻擊所造成的傷害能夠通過單純退回而消除則不需要RRD」,這種可以查詢。個人認為「X是笨蛋」、「Y是狗屎」、「Z不得好死」均屬於這類謾罵。另一方面,「X暗地勾結市長進行殺人活動」、「Y暗地裡進行女廁所偷窺」、「Z的屁股上面有個痣」這種則需要RRD,而不能查詢。請問這個標準是否合適?Bluedeck 2018年2月21日 (三) 09:05 (UTC)
- 單純意見,此不屬任何方針指引,我反對提高任何沒意義、沒營養,單存發洩、謾罵的歷史能見度。--Zest 2018年2月21日 (三) 10:11 (UTC)
- 這個頁面的本意應該是把還有搶救價值的條目拖回來使作者能改進吧?不過好像找不到該頁面相應的方針?--E8×E8(34) 2018年2月21日 (三) 13:00 (UTC)
- 頁面的另一個作用是使得社群得以觀察一項刪除決定合理與否,從這個角度看,我認為允許查詢沒營養的人身攻擊內容對整個管理員操作的透明度有積極作用。Bluedeck 2018年2月22日 (四) 00:08 (UTC)
- 這個頁面的本意應該是把還有搶救價值的條目拖回來使作者能改進吧?不過好像找不到該頁面相應的方針?--E8×E8(34) 2018年2月21日 (三) 13:00 (UTC)
- 單純意見,此不屬任何方針指引,我反對提高任何沒意義、沒營養,單存發洩、謾罵的歷史能見度。--Zest 2018年2月21日 (三) 10:11 (UTC)
- 我認為是可以的,之前也查詢過類似「fuck」這樣的頁面。我在這裡的標準同於RRD2一致,即「破壞、辱罵、人身攻擊所造成的傷害能夠通過單純退回而消除則不需要RRD」,這種可以查詢。個人認為「X是笨蛋」、「Y是狗屎」、「Z不得好死」均屬於這類謾罵。另一方面,「X暗地勾結市長進行殺人活動」、「Y暗地裡進行女廁所偷窺」、「Z的屁股上面有個痣」這種則需要RRD,而不能查詢。請問這個標準是否合適?Bluedeck 2018年2月21日 (三) 09:05 (UTC)
- @Bluedeck:請看一下你這次查詢的全部頁面,一堆屬於人身攻擊的,請求處理。--Zest 2018年2月21日 (三) 05:24 (UTC)
- 現在有很多攻擊其他用戶的頁面被查詢後貼了出來。--E8×E8(724) 2018年2月21日 (三) 04:17 (UTC)
「無爭議頁面直接復原」節
[編輯]請加入有關O7的附註。Sænmōsà中動員令:為西雅圖橋梁列表消綠 2018年7月13日 (五) 12:19 (UTC)
- 謝謝建議,長期以來沒看到,現在已經完成了。Bluedeck 2018年9月26日 (三) 17:36 (UTC)
查詢用戶自己刪除的內容是否合適呢?
[編輯]是否可以查詢Wikipedia:已刪除內容查詢#User:DGideas/oops類似這種呢?如果用戶有不再想讓大家看到的內容,我們是否應該讓用戶有權拒絕將這個內容公之於眾呢?我覺得這不是應該由我一個人決定的問題。我徵求一下社區的意見。Bluedeck 2018年9月11日 (二) 21:27 (UTC)
- (+)支持O1隻能由自己查詢,除非是管理員需要某些證據(不過那也不用走AR了)。--Yangfl(留言) 2018年9月12日 (三) 02:46 (UTC)
- 訴諸常識。理論上所有提交的內容都依照知識共享協議發布了,隱私內容應該監督。但實際執行中,也應該尊重其他人的意願,WP:禮儀。--YFdyh000(留言) 2018年9月12日 (三) 11:08 (UTC)
- 如果單純滿足好奇心就不要了。管理人員選舉、需要查案的情況例外。--Temp3600(留言) 2018年9月12日 (三) 15:53 (UTC)
- (-)反對,已經發布出來的內容不存在隱私這一說,G10或O1的頁面不應有特例。->>Vocal&Guitar->>留言 2018年9月13日 (四) 00:28 (UTC)
- 雖然這麼說理論上沒錯,但隨意查看別人已刪除的內容實在不是得體的行為,而且也會給AR帶來不好的影響。至於G10,不涉及用戶頁不在禮儀範圍。--Yangfl(留言) 2018年9月13日 (四) 01:17 (UTC)
- (+)支持,只有用戶本人自己能看。Jane9306·TWICE❤·One In A Million ! 2018年9月13日 (四) 12:10 (UTC)
- (!)意見 這種情況,就請管理員概括一下內容,不必列出全部歷史 116.192.198.9(留言) 2018年9月13日 (四) 12:13 (UTC)
- 反過來說,查詢已刪內容本身應該提出合理原因,例如要改善條目。因此,查閱用戶子頁面也應該有相對的合理原因才行。—AT 2018年9月13日 (四) 16:43 (UTC)
- (?)不解那有沒有程式碼可以只讓查詢者看見?-- Sunny00217 2018年9月18日 (二) 14:47 (UTC)
- 除非我採用特殊的手段,比如查詢結果放在站外要求密碼的地方,然後把密碼發給查詢者。如果放在站內,就是大家可見。Bluedeck 2018年9月19日 (三) 03:45 (UTC)
- 可以用站內的郵件功能發給查詢者,只要他綁了郵箱並且沒關選項。--YFdyh000(留言) 2018年9月20日 (四) 23:46 (UTC)
- 簡單說一下我自己的思路:目前的方針並沒有阻止查詢的進行,但是我們正在尋求一個新的共識,所以這是可以改變的。我一開始也是持着「已經發布出來的內容不存在隱私這一說」這個觀點看的。我認為既然維基百科數據都是公開的,那麼可以輕易建立站點收集O1內容。但是隨着思考和經歷的增加,尤其受到GDPR中「被遺忘權」這一點的啟發,我的看法也在漸漸轉變。我現在覺得應該在用戶自己選擇刪除頁面之後尊重他/她當時的考慮。如果想要看的話,應該問他本人的意見,或者有些重要的理由。這是我現在的想法,我說一下。Bluedeck 2018年9月19日 (三) 03:49 (UTC)
- 1.用戶頁的所有權並不屬於用戶個人;2.個人信息應當尋求OS;3.被遺忘權有較大爭議,尚未形成一定的規則。在現有方針下,用戶可請求刪除,他人也可去查詢。我不反對閣下推動修改方針,但我個人會秉持反對的態度。->>Vocal&Guitar->>留言 2018年9月21日 (五) 12:45 (UTC)
- (!)意見那是否可以加入非用戶本人不給資料?— Sunny00217 2018年9月19日 (三) 19:52 (UTC)
- (!)意見可以把「獲得用戶同意」作為條件之一。——C933103(留言) 2018年9月20日 (四) 05:03 (UTC)
- 這對於非私人內容可能過於嚴格和沒有必要,用戶可能無法聯繫到。--YFdyh000(留言) 2018年9月20日 (四) 23:46 (UTC)
- 連不到就不能查阿-- Sunny00217 2018年9月25日 (二) 14:02 (UTC)
- 這對於非私人內容可能過於嚴格和沒有必要,用戶可能無法聯繫到。--YFdyh000(留言) 2018年9月20日 (四) 23:46 (UTC)
- 本站資源蓋應用於改善本站,既然已刪除內容查詢會使用本站資源,那重點就應該在申請是否能夠幫助本站改進。如只在滿足一己好奇,那無論是否用戶頁都應該拒絕相關申請。用戶申請時理應附上理據。只要秉持這個宗旨,亦不必去爭論要不要考慮「被遺忘權」。--J.Wong 2018年9月28日 (五) 17:22 (UTC)
- 我覺得很多好奇應該是好奇為什麼刪除或者刪除是否合理。這是一種有建設意義的好奇,可以查詢。Bluedeck 2018年10月3日 (三) 18:07 (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月5日 (五) 15:49 (UTC)
已刪除查詢改為移動?
[編輯]- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
對於大的頁面,這個功能占用數十MB磁盤。舉一個最近遇到的比較極端的例子,一個頁面500+版本,每個版本50+kb,查詢一次約消耗25MB磁碟。加上數據庫結構文件可能比25MB還大一點。
小的頁面沒什麼問題,但是我想當遇到100個以上版本的已刪除,能不能直接恢復到WP:已刪除內容查詢/查詢中去,不用特別的複製一份呢?反正效果其實不差。
(其實小的頁面也可以直接恢復,移動到上述位置)
雖然說不要在意性能,但是既然效果完全一樣,那麼是否可以通過這個方法節約一點磁盤呢?之前曾有人跟我說過這樣的話刪除不是跟沒刪一樣了嗎。但是英文版就是這樣,有想要的會恢復。而且目前的查詢和恢復也相差無幾了。Bluedeck 2018年10月8日 (一) 23:52 (UTC)
- (?)疑問具體是要改什麼方針指引?還是討論而已?是否VPO比較恰當?--Cohaf(留言) 2018年10月9日 (二) 01:56 (UTC)
- @Bluedeck:本人相信伺服器管理人員應該會壓縮資料的…… - まっすろな未來 2018年10月9日 (二) 02:54 (UTC)
- 回復cohaf:確實不是一個直接修改方針指引的討論,不過會對刪除方針構成一些影響,所以放在哪邊都可以吧。回純白未來:確實採用gzip壓縮,但是我認為壓縮設置為32kb回溯窗口(具體不知道),應該不會特別有效的壓縮50kb的頁面。Bluedeck 2018年10月9日 (二) 03:47 (UTC)
- 藍桌啊,我認為還是那句老話——Wikipedia:不要擔心性能。——路過圍觀的Sakamotosan | 避免做作,免敬 2018年10月9日 (二) 05:17 (UTC)
- 回復cohaf:確實不是一個直接修改方針指引的討論,不過會對刪除方針構成一些影響,所以放在哪邊都可以吧。回純白未來:確實採用gzip壓縮,但是我認為壓縮設置為32kb回溯窗口(具體不知道),應該不會特別有效的壓縮50kb的頁面。Bluedeck 2018年10月9日 (二) 03:47 (UTC)
- 前幾天在#wikimedia-tech上問過,WMF wiki配置了外部存儲,
text
表里只有指針,數據庫本身不存歷史版本。-Mys_721tx(留言) 2018年10月9日 (二) 06:42 (UTC)- 所以大家的結論是繼續複製text嘛 >< Bluedeck 2018年10月9日 (二) 17:45 (UTC)
- 雖然「不要擔心性能」,但所有版本另複製一份,感覺確實不太好,對執行人和系統的編輯數也有注水。但是,如果是直接移動,不是與存廢覆核流程差不多了嗎,當查詢的頁面要覆核/復原時怎麼處理。--YFdyh000(留言) 2018年10月9日 (二) 23:21 (UTC)
- 如果操作流程是:創建條目A,刪除條目A,復原並不留重定向移動至「AR/查詢A」。那麼此後,管理員再次查看條目A的已刪除版本時將不會看到之前被刪除的版本,因為這些版本現在在「AR/查詢A」。如果確實時如此操作,那麼最終結果對於其他站務還是有一定影響的。--Tiger(留言) 2018年10月10日 (三) 01:21 (UTC)
- 管理員會看到移動記錄裡面有移動到了AR/查詢/A的記載的,應該沒有導致紊亂的危險。Bluedeck 2018年10月10日 (三) 05:14 (UTC)
- 小心被搜尋引擎看到。--Temp3600(留言) 2018年10月10日 (三) 06:24 (UTC)
- (-)反對:若是在條目A又新建新內容呢?(機率造成歷史資料不一)-- Sunny00217 --邀請你一同關注歷史上的今天 2018年10月12日 (五) 13:13 (UTC)
- (-)反對:如果有多於一人重複查閱同一頁面的話,會造成不便。Sænmōsà請多多關注香港西九龍站條目同行評審 2018年10月13日 (六) 07:49 (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
[編輯]
|
|
Tldr幾個主要修改:
- 明文規範申請應有合理理由。Xiplus提到基於法律原因已刪內容僅允許管理員可以瀏覽。繞過這個限制必須檢查有關請求是否合理。
- 明文規範無爭議頁面還原應前往存廢覆核請求,這種頁面應還原整個頁面歷史。由於AR非管理員亦可處理,這種請求應前往DRV。
- 規範G3或G12內容如無合理理由不可查詢,見上討論。
- 副抄U:Xiplus參與討論-某人✉ 2021年10月16日 (六) 05:40 (UTC)
- 就算有此限制,如果去找管理員找回我不認為會被拒絕。請出@Bluedeck--拒食木瓜卄 2021年10月16日 (六) 06:47 (UTC)
- 另外,我不反對O7等轉至存廢覆核處理,但請不要超前部屬。--拒食木瓜卄 2021年10月16日 (六) 11:59 (UTC)
- 一案兩提我直接關掉一處我不認為有問題-某人✉ 2021年10月16日 (六) 12:09 (UTC)
- 想請問一下「取回自己的創作成果」是合理的查詢理由嗎?如果是,但其內容爲G3等、基於某種個人考量不願意提供電子郵件,請問要如何查詢?--拒食木瓜卄 2021年10月17日 (日) 01:37 (UTC)
- 不予查詢。AR的本意是讓想重寫條目的人不會完全失去以往成果。如果其「創作成果」是G3的話就證明他的行為根本與編輯維基百科無關,不是合理理由。所謂「合理理由」是如上面Sanmosa所說研究LTA行為等-某人✉ 2021年10月18日 (一) 01:20 (UTC)
- 曾經有討論過,有觀點認為可以查詢內容類似「fuck」的頁面,這樣能使刪除操作和理據更透明(也即普通用戶能檢查是否刪除合理)。--GZWDer(留言) 2021年10月17日 (日) 06:58 (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)
- 未見明顯反對,開始公示. CC@AnYiLin、Sanmosa、Jonathan5566:-某人✉ 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)
- 我來明顯(-)反對一下哈。為了說明我的觀點,我先提出一個問題,沒有理由拒絕查詢是吧,那假如說有三個人來查詢三個「明顯擾亂頁面」,分別給出的理由是1)「想看」,2)想親自確認內容是否符合刪除標準,3)可能會有有用的內容但是我看不見所以想查詢。請問這三個理由中有哪些是有效理由呢?如果有無效的理由,為什麼無效?Bluedeck 2021年10月21日 (四) 05:44 (UTC)
- 我不喜歡上面的提案內容。--Xiplus#Talk 2021年10月22日 (五) 03:01 (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)
- @Bluedeck:你的反對原因是否已被解決?如無更多意見即日起以Xiplus版本重新公示-某人✉ 2021年10月25日 (一) 13:45 (UTC)
- @AINH:請確認公示是否通過。--Sanmosa Ázijská Práca 2021年11月1日 (一) 06:47 (UTC)
幫助=>zh-tw:說明
--Winston Sung(留言) 2021年10月29日 (五) 02:55 (UTC)- @Sanmosa:
- Module:CGroup/MediaWiki中的「Help:」是用於轉換命名空間的,另幫助不是每次都轉換為說明。--Winston Sung(留言) 2021年11月1日 (一) 03:50 (UTC)
- 公示期間無異議,通過-某人✉ 2021年11月1日 (一) 06:55 (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)
- 希望更多管理員能投入到此類事務上面來。—— Eric Liu 創造は生命(留言.留名.學生會) 2022年2月20日 (日) 11:36 (UTC)