维基百科讨论:已删除内容查询
服务名称
当初使用查询而非请求,主要的考虑是更加亲民。现在这个名字已经使用了多年,将名字套用到公开页面上,令老用户熟悉。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)