维基百科:互助客栈/其他/存档/2022年6月
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
管理员投票选民名单不符合程序方针
纠正历史上阴阳家的错误
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
很不幸的是历史上这种前人的错误,不是我们后人能纠正的。
一个中国文化的特征而世上也是独一无二的,那就是中国古代的阴阳学。阴阳学的晢理至深,一般世人无法了解,以讹传讹,传至其末,“不知所云”,属性与本质是两码事。这种前人的错误,不是我们后人能纠正的,在这里我们没有理由去追求那些“以讹传讹” 的阴阳属性,那只能越描越黑。我们必需从新来过。
根据太极图,那不是两个蝌蚪挤在一个圆圈里,而是一对黑白象征性的代表一个阴阳整体,黑里一点白,白里一点黑,隐藏着“阴阳错”的天机(“错” 作交错或是错过解)。
https://upload.wikimedia.org/wikipedia/commons/1/17/Yin_yang.svg
见图,阴阳表现四个不同又相关又不能分的特性:
一)对立统一。那是阴阳相对而形成一体。
二)相克相生。阴长克阳,同时助阳复生,反之亦然。
三)物极必反。阴极变阳,而阳极变阴。
四)极尽平衡。极尽—最终—阴阳总是平衡的;那是说,阴阳总是追寻平衡的。
那“四个不同又相关而不能分的特性” 是个很高深的学问,世人不能理解,谓之诡谲/邪术,终于在魏晋朝时代失传,只有一个太极图和一些阴阳的“属性” (里外,上下,男女等等) 留传下来。
用语言吾人可以定义任何事物,但是它存在吗?定义没有实物与其对应只是一个幻想。根据上述阴阳的特性,阴阳是不能分的,所以是“一元” ,当阴阳家创“阴阳二元论” 时,阴阳一元的本质尽失,阴阳家是始作俑者,后世跟着错。那什么是真正的阴阳呢?“阴入阳出” ,呼吸也。世上万物,只有呼吸附合那四个阴阳的特性,呼吸是“一元” 世界的元素,二元世界不过是一元世界的幻想。
证明:一)对立统一:吾人呼吸,一呼一吸,然后循环,我们不能只呼不吸,或是只吸不呼,所以呼吸是不能分的一体—“一元”—对立统一。 二)相克相生:当我们吸气时,越吸越难吸,同时呼气比较容易,那是吸气克呼气,同时助呼气复生—相克相生。 三)物极必反:当我们吸气吸到尽头不能再吸的时候(物极),必然呼气,反之亦然—物极必反。 四)极尽平衡:吾人要是活着,呼吸一定平衡—极尽平衡。
阴阳二元论说不定是一门学问,但是其主题的对象不是我们中国古典的阴阳一元论的阴阳。 --太极滑雪(留言) 2022年6月4日 (六) 18:32 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
任天堂明星大乱斗系列角色列表的角色插图
注入特制的TCP数据包是否需要承担法律风险
在谷歌搜索维基百科论述疑似被劫持
在谷歌搜索维基百科:热血速删,发现搜索结果被劫持到一个叫“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)
欢迎各位加入存废复核志愿参与工作小组
一个可能会发生的法律问题
重启逐笔巡查标记的讨论
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
如题,之前有提过是否能对每一笔编辑进行逐笔巡查的标记,以避免巡查员重复巡查同一篇文章的问题,不过好像最后结论就不了了之,因此希望能重启讨论。
在前一篇讨论中,有很多人担心巡查人力的问题,这部分我回复一下,就是因为现行巡查人力不足,所以我们更应该改善巡查的效率,让每位巡查员一打开巡查页面就能知道什么编辑尚未审查,而不是像现在一样每笔点开来看,如同大海捞针。至于担心巡查员积压工作的问题,我想这并不是一个很好的理由,逐笔巡查对反破坏工作来说非常重要,并不是说不打开这个工具就可以当作现在这个工作不存在。--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)
- 最近更改的过滤器功能现在挺强的。可以用最近更改-“监视列表新更改”过滤器。--YFdyh000(留言) 2022年5月9日 (一) 09:59 (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)
- 那也没办法,有些破坏行为是偶然看条目发现不对劲才去翻查页面历史的,不可能靠整天蹲着最近更新来“扫描”(好吧,虽然有工具是可以这么干的),要不然这是严重的中毒了。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月9日 (一) 23:33 (UTC)
- 我有开,但感觉不知道评断依据是什么?而且似乎大多数的破坏反而都不在标记中。另外会需要蹲点巡查就是因为有些蓄意破坏很难透过字节或用户加入时间去判断。--Koala0090(留言) 2022年5月9日 (一) 18:08 (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)
- 看了之前的讨论,技术上似乎无法区分新页面巡查豁免和编辑巡查豁免。--Steven Sun(留言) 2022年5月15日 (日) 02:11 (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)
- 我觉得可以开啊,但我觉得没必要用机器人自动巡查,最近更改本来就可以筛选30/500,跟90/500也差不多吧,用这个就行了。--Xiplus#Talk 2022年5月15日 (日) 06:30 (UTC)
- @Xiplus 开启逐笔巡查以及利用机器人标记巡查豁免者--Koala0090(留言) 2022年5月15日 (日) 06:25 (UTC)
- 哪个部分?--Xiplus#Talk 2022年5月15日 (日) 04:42 (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)
- 近百个wiki开启此功能。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)
- 技术层面上,这个功能能够启用吗?(已经发生过多次搞不清楚状况,最后提交到phab那里被拒。。。)--百無一用是書生 (☎) 2022年5月18日 (三) 02:39 (UTC)
- 不需要定死时间吧,有共识再关闭。开关都需要phab那边完成。--YFdyh000(留言) 2022年5月15日 (日) 22:35 (UTC)
- 先试三个月看看好不好?直接一次通过我担心没能完全消掉社群的疑虑。--Ghren🐦🕙 2022年5月15日 (日) 14:31 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
- 感觉启用后实在没啥意义,全都是红色感叹号,而且修订历史里还没有这个标记,只有最近更改和监视列表里才有--百無一用是書生 (☎) 2022年5月23日 (一) 14:56 (UTC)
- 目前看来回退和复原后并不会自动标记已巡查,若是如此,认为可能需要提醒所有巡查员要记得点选已巡查,不然还是要每笔点开来看。0906(回复请Ping我) 2022年5月23日 (一) 16:30 (UTC)
- 对我也发现这个问题了,有办法将某些设定设定为自动巡查吗,例如说回退之类的。--Koala0090(留言) 2022年5月23日 (一) 16:32 (UTC)
- 另外就是因为我有开启小工具,可以在不点开画面的状况下进行依些简单的巡查。但因为最新更改清单中没有巡查按钮,还是要点进去才能巡查。不知道之后可不可以在后面加上一个巡查按钮--Koala0090(留言) 2022年5月23日 (一) 16:37 (UTC)
- 0906(回复请Ping我) 2022年5月23日 (一) 18:57 (UTC)
- @ChhTJ096:全都是靠外部脚本运作的配套功能,为什么要靠脚本来清除?所以说,这个功能,为什么不从一开始就考虑解决后续的问题(一些用户或者大部分用户并不需要这些标记,或者说还需要考虑部分用户组的编辑可能不需要被这样标记)。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 02:21 (UTC)
如果使用TW不知道可否自动标记,还有管理员、机器人应该可以自动免巡查吧....--
- 0906(回复请Ping我) 2022年5月23日 (一) 18:57 (UTC)
- 另外就是因为我有开启小工具,可以在不点开画面的状况下进行依些简单的巡查。但因为最新更改清单中没有巡查按钮,还是要点进去才能巡查。不知道之后可不可以在后面加上一个巡查按钮--Koala0090(留言) 2022年5月23日 (一) 16:37 (UTC)
-- - 对我也发现这个问题了,有办法将某些设定设定为自动巡查吗,例如说回退之类的。--Koala0090(留言) 2022年5月23日 (一) 16:32 (UTC)
- 目前看来回退和复原后并不会自动标记已巡查,若是如此,认为可能需要提醒所有巡查员要记得点选已巡查,不然还是要每笔点开来看。0906(回复请Ping我) 2022年5月23日 (一) 16:30 (UTC)
- 很困惑的鸡肋功能,而且还要靠额外的手段来清理掉一些不必要的标识。只为其中一位编辑的识别能力弱而特此开启该功能,真的是……——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 01:45 (UTC)
- 祝某些编辑“消消乐”愉快。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 01:49 (UTC)
- 没价值的引战留言恕我不回复了--Koala0090(留言) 2022年5月24日 (二) 06:22 (UTC)
- 祝某些编辑“消消乐”愉快。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 01:49 (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)
- Wikipedia:最近更改巡查没有用户组,而Wikipedia:新页面巡查关联的用户组“巡查员”的核心权限就是“patrol”功能权限,也就是想做Wikipedia:最近更改巡查工作,现时肯定就要成为“新页面巡查”人员,才能拥有核心权限及对应的权利(启用逐笔巡查功能(非特设的话,默认关闭),则最近更新和监视列表能区分有没标记巡查的编辑,启用了新页面巡查功能(非特设的话,默认开启),则新页面能区分有没标记巡查的编辑,新文件巡查功能也是同新页面同理)。为了给每笔没问题的编辑标记没问题来提醒其他不一定相关的人员“没问题”,而特意去申请一个为新页面做巡查的职务或用户组,我觉得哪里不对。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 10:05 (UTC)
- 有必要的话会进行权限拆分。--Xiplus#Talk 2022年5月25日 (三) 09:30 (UTC)
- 那问题是这样做有意义吗?然后让一个对Wikipedia:最近更改巡查有兴趣的用户,特意去申请加入“Wikipedia:新页面巡查”去获得“标记巡查”功能,然后就是为了给没有问题的编辑做标记,然后通过这样告诉其他“Wikipedia:新页面巡查”人员“哦,这个编辑没问题,这个编辑也没有问题,这些编辑也没有问题”?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 09:18 (UTC)
- 如果是好编辑,那就别管它,关掉窗口或者忽略掉就是了。如果是坏编辑,请行动,或者已经有人行动了。“逐笔标记”并非必要。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 07:18 (UTC)
- “没点击差异进去之前,最近更新已经提示有下一笔编辑了”那如果没有下一笔编辑,但这笔编辑实际上已经由别人检查过的话呢?--Xiplus#Talk 2022年5月25日 (三) 06:29 (UTC)
- 我认为还是一个问题,没搞清楚WP:新页面巡查和Wikipedia:最近更改巡查的意义,原则上新条目应该被标记巡查掉(现在就是人力原因或者其他原因,导致了经常超期,而且也不会影响条目的显示),“标记掉”就是“暗示”给其他“新页面巡查”人员这个条目已经巡查过。而执行“最近更改巡查”工作的用户,添加了修葺标识、撤销了一笔破坏,与“标记掉”有没必要的关联?没有,而且看是否存在后续编辑就知道是否被处理过。而且也提及过,由于技术同源,这个功能是对“新页面巡查”人员有影响也只对“新页面巡查”人员有意义,但对于“新页面巡查”人员来说,这个功能(连“逐笔编辑”都可以或者需要标记巡查)是否具有必要性?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:55 (UTC)
- Re“有必要每一笔编辑操作都需要人力确认有问题或者没问题”:没有检查到就算了,这同理于存在积压的新页面巡查,所以我们才需要“标记功能”来让仅有的人力效益最大化,如果每个巡查员每天能巡查10个条目,那么2个巡查员最多可以巡查20个条目,如果没有将新条目标记为已巡查的功能,那么这2位巡查员就可能检查到重复的条目,导致总巡查量降低。同理如果有2位志愿巡查最近更改的人,而分别每天能检查100笔编辑,那总检查量最高是200编辑,但如果没有将编辑标记为已巡查的功能,那么这2位检查到重复的编辑,就会让总检查量降低。--Xiplus#Talk 2022年5月25日 (三) 04:44 (UTC)
- 特定一笔编辑“挂修葺标示”和“标记巡查”在“Wikipedia:最近更改巡查”中有必要的关联?或者说,有必要每一笔编辑操作都需要人力确认有问题或者没问题,来消除这个巡查提醒?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:36 (UTC)
- “新页面巡查有着更多的操作(分析页面并且挂标示或者编辑改善)”难道一个文字内容在建立页面时需要挂模板,但如果建立条目一段时间后再加入同样的文字内容就不用挂模板吗?--Xiplus#Talk 2022年5月25日 (三) 04:32 (UTC)
- 既然知道这是同源技术,那么新页面巡查就是巡查这个页面的第1笔编辑,最近更改巡查就是巡查这个页面的第2、3、4笔编辑,实际并无差异。就算已经有巡查员群组,所有人都还是可以参与新页面巡查,而巡查权限本质上只是一个“告知其他人不需要再检查一遍这个条目”的权力而已,同理,提案人只是需要“告知其他人不需要再检查一遍这个编辑”的功能。--Xiplus#Talk 2022年5月25日 (三) 03:09 (UTC)
- “‘我’不需要用到”不等于“你需要用到就启用”,而且我也留意到一些用户也疑惑启用的必要性。而且“最近巡查”并不是“点击标记”,且不依赖于“点击标记”,你的想法是假设有最近巡查的人员会重复巡查,但问题当发现怀疑破坏后,不应该直接点击差异进去看一下有没之后的编辑(可能有其他用户已经发现而撤回,又或者不只是这一笔还有后续)?只要能做到这步,就不会出现重复巡查的问题(因为前述,如果没被处理就肯定这个“破坏”处理或者还有后续,这就更需要看页面历史),所以这个最近更改的标记就没有意义。而且没有CSS修饰的话,的确可以肯定已经对众多有巡查权限的用户造成困扰,而且我不认同靠CSS来掩耳盗铃来处理(甚至没有其他mw-core的功能配套下,依靠外部的行动来标记“可信”的编辑)。如果只是某些编辑为了防止自己的失误的话,应该自行解决,而不应该用大炮打蚊子的方法,还要搞出额外的操作来换更小的大炮打蚊子来避免。甚至最近巡查真靠逐个标记来排除破坏,而不是通过观察编辑行为来判断?———Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 09:49 (UTC)
- 其实本来这个状况就是有预期到的,首先开启第一天,有许多巡查员尚不知有这个功能;第二就是这个工具缺乏自动标记功能。如果要解决的话应该是可以透过改善自动标记某些巡查功能,真的不能做到再关闭。每个新工具上线之初本来就会有问题,本来就需要一段时间的测试和调整。每个人的需求不同,如果因为你个人“不需要用到”这个因素而去阻止其他新工具的开发,那其实对于整个社群的进步是有危害的。例如说视觉化编辑上线初期,也是出现了很多反对的声音,有些人说“源代码用得好好的,为什么要开发这么难用的工具!”但对于许多不会源代码的新手,这个工具还是相当重要的,如果还是用你那论调主张“只有少部分编程语言能力低落的用户需要用到”,那就会阻碍很多人参与和工作。总之,言尽于此,若阁下后续有价值的留言我会适予回复,单纯来引战和人身攻击的就上ANM,这样。--Koala0090(留言) 2022年5月24日 (二) 06:37 (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
- 那只能之后看支持启用的人有多大的意愿去做这种消消乐的活了。(摊手)——Sakamotosan路过围观 | 避免做作,免敬 2022年5月31日 (二) 04:50 (UTC)
- 只要有两个人愿意做标记,那么这两个人就能够省下彼此的时间。其他不参与的人一样会有重工的问题,但其他人要浪费自己的时间我管不着。--Xiplus#Talk 2022年5月30日 (一) 15:23 (UTC)+1
- 要么就是“最近巡查”的志愿行动和“新页面巡查”职务性行动因为启用“逐笔巡查”后的冲突(“逐笔巡查”需要用到“新页面巡查”的“patrol”功能);要么就是你所说的重复检查需要靠标记来区分,我认为这个需要数据统计,究竟有多少用户愿意去做这样的标记行为。我认为应该根据已开启该功能的wiki项目的最近变更数据来统计,如果很少人使用这个功能或者能力(也就是最近编辑中,手工标记的页面编辑的比例很低甚至几乎没有),那就说明这个功能就是鸡肋功能,没必要凑热闹来开。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月30日 (一) 02:02 (UTC)
- 以前就有重工问题,您是不是根本不懂哪里重工。--Xiplus#Talk 2022年5月29日 (日) 11:33 (UTC)
- 近百wiki启用功能并不能说明普遍性(反而你需要倒转数一下有多少wiki是默认关闭的,为什么这个“逐笔编辑标记”不是普遍使用,反而同源的“新页面标记”和“新页面标记”反而是默认启用的),你应该说明这些wiki是否有大量使用这个功能(也就是经常地使用逐笔标记),否则就会出现某些用户不会(有功能者)或不能(没功能者)标记正常编辑或者已处理的编辑而还是存在重复“巡查”的问题。至于“重工”问题,最简单的处理就是把这个鸡肋功能关闭掉,让一切回归以前。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月29日 (日) 11:24 (UTC)
- 参考该功能开发初期的讨论,我认为好的编辑不需要特意标记(旧en讨论也有人提到,假设所有编辑都是可疑的来去标记不是好的wiki风格),坏的编辑直接操作处理则可;坏的编辑处理好后还需要额外的操作来标记之前被破坏的编辑(除了core-rollback似乎能直接标记,但留意到巡查日子似乎没记录);粗略看了commons的巡查日志,似乎也很少人会做“逐笔编辑标记”的操作,在旧en讨论中也提到这个问题。所以既然这个功能从一开发后就被遗弃,单独启用了的也似乎是鸡肋一样少用,我不认有启用的必要。而且这个功能更依赖于“新页面巡查”用户组的“patrol”权限,对于只做“最新巡查工作”但不属于这个用户组的用户来说,似乎并不合适。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月27日 (五) 05:59 (UTC)
- 开发新的外部工具就不会被你嫌弃吗?--Xiplus#Talk 2022年5月27日 (五) 04:33 (UTC)
- 为了使用一个从一开始开发完就被嫌弃的“新”功能,而去别扭地适配使用,还要靠外部工具去“修正”,还不如不用。因为你提到拆分权限,我无法确定你的想法,我猜想可能是将“patrol”功能拆成适配新页面、新文件、逐版本编辑的“patrol”,然后重新分配用户组?所以这意味着是不是还要找mw开发组进行功能适配?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月26日 (四) 02:26 (UTC)
- 拆分权限比开发新功能简单多了,mw开发新功能不行,开发外部工具就可以,是什么道理?--Xiplus#Talk 2022年5月25日 (三) 10:21 (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)
- 话说,这是已经关掉了吗?现在我已经看不到红色感叹号了(除了新建页面)。另外,我认为其他wiki很少标记,可能更多的原因是具有“巡查标记”功能的用户组门槛很低,类似于自动确认用户那样。如果中文版这边没有类似机制,导致的后果就是一片红色的感叹号。另外,我对监视列表里的编辑,不会因为有感叹号标记而去特意查看并“标记为已巡查”,也不会因为没有感叹号或已经巡查而就不去看了。最后,这个功能到底我们社群有多大的需求?--百無一用是書生 (☎) 2022年5月24日 (二) 12:35 (UTC)
- CSS屏蔽,然后对有巡查权但认为不需要逐笔巡查的用户,不就跟以前一样吗?--YFdyh000(留言) 2022年5月24日 (二) 10:03 (UTC)
- CSS屏蔽,或者依靠外部行动来标记没有功能豁免的编辑,我认为不就是掩耳盗铃?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月24日 (二) 09:53 (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)
- 另外,实操上,我看到一个好的编辑我可能会标记巡查,但对于坏的编辑我可能直接回退而不会标记为巡查(因为操作太繁琐)。所以我感觉这个逻辑上有些怪--百無一用是書生 (☎) 2022年5月25日 (三) 06:43 (UTC)
- 我认为最近更改巡查对于small wiki或许有些意义,对于更新相当多的wiki完全没有实用价值--百無一用是書生 (☎) 2022年5月25日 (三) 06:40 (UTC)
- 你应该问Huggle或SWViewer的开发,这样外部的最近更新追踪工具有什么作用,就是为了给自己标记自己已经“复核”过的每笔编辑?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:58 (UTC)
- MediaWiki本身就有这样的功能,不理解为何一定要开发新的。--Xiplus#Talk 2022年5月25日 (三) 04:46 (UTC)
- 这只是对这些外部工具对过往记录的回溯能力需求吧?有这个需求的话可以向相关工具开发提出(core-API没记错,最近更新列表似乎可以指定回溯的时间?)。如果这些工具长期启动的话,也可以回溯已经发生过的编辑?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 04:26 (UTC)
- 请问哪个工具可以检查一个小时前的编辑?Huggle或SWViewer可以吗?这些工具都仅能检查当下新出现的编辑吧。--Xiplus#Talk 2022年5月25日 (三) 03:12 (UTC)
- 我的意见就是这个意思,“最近更新巡查”因为定性于非职权性(没有用户组,而且逐笔标记似乎过于鸡肋,以至于很早(根据配置文件,似乎是en在2005年的讨论)被默认禁止了),只需要辅助工具就能解决,如果避免重复巡查的话,完全可以依靠这些工具来实现。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月25日 (三) 01:10 (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)
- 或者严格一点,damaging为false且goodfaith为true的自动巡查?你那个0.027的条件说实话我不理解为什么设定这个值?当然,ORES给出的数据我也不是看的很明白[1]。另外,可以参考mw:ORES/Thresholds--百無一用是書生 (☎) 2022年6月9日 (四) 07:05 (UTC)
- 我忘记是从哪里看到的了,但似乎有说法说这两个模型的训练方式不是很一样;既然goodfaith有更高的recall rate,那可以选用它。我也没有仔细看过文档……这个页面可能有点帮助。 Stang★ 2022年6月9日 (四) 04:34 (UTC)
- 还有,为何不直接用prediction的真假值,而要用分数做判断?ORES这一块我没仔细看过文档,不太了解--百無一用是書生 (☎) 2022年6月9日 (四) 01:57 (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)
- 成本不高,有一两个人愿意持续做就可以,存废讨论、关注度等很多维护也并没有很多人坚持。我更关心的是,筛出来的有问题或有争议的编辑/编者,是否能得到妥善讨论和处理,以及标记巡查本身的尺度与责任性。--YFdyh000(留言) 2022年6月9日 (四) 09:34 (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)
跨命名空间重定向
是否可以为他人翻译的条目添加{{Translated page}}
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)