跳转到内容

英文维基 | 中文维基 | 日文维基 | 草榴社区

维基百科讨论:新条目推荐/候选/存档10

页面内容不支持其他语言。
维基百科,自由的百科全书

在条目通过新条目推荐之后跑到讨论留下反对要怎么处理?

完成,可选择标示为无效、回退该编辑或提报至破坏处理。不过DYK此种情况并没特别看过先例,如要决定该情况怎处理者建议日后开一个新讨论串。--Z7504非常建议必要时多关注评选留言2020年1月21日 (二) 10:36 (UTC)

下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

请问就装作没看到还是直接回退?发生问题的条目于此“讨论:人中之龙7 光与暗的去向” --无心*插柳*柳橙汁 2020年1月15日 (三) 06:50 (UTC)

按存档后修改的情况处理。——路过围观的Sakamotosan | 避免做作,免敬 2020年1月16日 (四) 01:52 (UTC)
我开了新段,那样就没事了。功成不必在我 2020年1月16日 (四) 08:07 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

提议修订DYK中“获选标准─投票期限”规则

依提案人意见先关闭。--Hjh474留言2020年3月20日 (五) 08:59 (UTC)

下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

现行条文

投票期限:基本投票期为4天。待至基本投票期届满时,如获得中选所需的最低票数或以上,投票即会结束并获通过;否则,投票期将自动延长3天,并待至延长投票期届满时方为结束投票;在结束时如获得中选所需的最低票数或以上,方获通过,否则以落选论。机器人将在相关日子自动计票。

提议条文

投票期限:投票期为7天。待至投票期届满时,如获得所需的最低净支持票数或以上,投票即会结束并获通过,反之以落选论将在相关日子计票;如为获得所需的最低净支持票数或以上却仍存在页面存废讨论 问题不当问题时,应待这些问题均获解决后才视为通过

理由有四:

  1. 现在机器人(Liangent-bot)不是不运作DYK了吗?
  2. 为什么明明有投票在4天期限内就达标却还是继续开放投票?
  3. 广宁城的DYK就可以看的出来 问题不当的“期限标准是指4天还是7天”就有争议了。如果对于问题不当而需要判落选的,请在底下提出更好的条文。
  4. 最后,大家真的有差那3天吗?会过的DYK自然而然就会过,不会的话给7天还不是没有人要理会?GA也是类似的道理啊。--Z7504非常建议必要时多关注评选留言2020年3月10日 (二) 07:22 (UTC)
(:)回应
  1. 自动点票机器人正在开发……
  2. 请注意手动批核会有时间差,您看到四天够四票还继续的投票,其实是因为我上次手动批核时它根本不够四天,管理员会不定时上来手动批核。
  3. {{问题不当}}不会导致落选,通过的结果会一直保留直到有合适的问题为止,四天后就算有人投反对都会视为无效,所以不构成4天还是7天的问题。
--街燈電箱150號 开箱维修 抄表 检验证明 2020年3月10日 (二) 08:23 (UTC)

现告终止公示。提案人并未解决所有的异议。另外,我正式反对提案。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫长夜 2020年3月20日 (五) 04:03 (UTC)

早就知道有人会有异议了,这样的话互助客栈真有保留的必要吗,反正互助客栈风气已经是没坏就不要修,大家都“懒得修”了,莫名其妙。--Z7504非常建议必要时多关注评选留言2020年3月20日 (五) 04:17 (UTC)}}


不忍见君Z7504心灰意冷,不好意思擅自重启,因本案相对单纯,微调条文后应该可以通过才是,毕竟机器人(Liangent-bot)已不运作DYK,恳请U:Sanmosa君建议如何调整,俾使本案通过,感谢。--Hjh474留言2020年3月20日 (五) 08:46 (UTC)

我反对任何形式的修改。君不见上面Cdip150正在说“自动点票机器人正在开发”吗(我担忧这会对开发造成负面影响)?另一方面,取消4日制度是大事,如果要通过,这么少的人参与讨论肯定是不够的,而且取消4日制度非常费时失事,我真的不认为这有任何好处,反而有坏处。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫长夜 2020年3月20日 (五) 08:49 (UTC)
了解。待“自动点票机器人”稳定后再讨论好了。--Hjh474留言2020年3月20日 (五) 08:59 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

维基不知道为什么傻了,弹出了很多同样的请求

我只是想铲除多出来的请求,但是他不给我做。请问怎么办?Cyril Yoshi (留言信箱) 前来签名吧! 祝贺港区国安法通过一星期 2020年7月15日 (三) 08:27 (UTC)

这也能被破坏?

建议以后设置永久性半保护嗷,,,角川かどかわ 淑子よしこ“不易流行” 2020年7月21日 (二) 02:09 (UTC)

协助DYK

请将达到标准的弄上DYK。




2001:B011:30E0:3015:486A:F203:B12E:8DDD留言2020年8月10日 (一) 01:34 (UTC)

编辑请求 2020-08-19

请求已拒绝

敝人发现这些主题条目值得上DYK,但是不知道是否符合标准,如果符合标准就请代为上DYK。不符合标准就请你们协助改善,谢谢

占版面内容已被移除

--2001:B011:30E0:31D6:6104:E5BF:B4F8:9079留言2020年8月19日 (三) 14:31 (UTC)

编辑请求 2020-08-21

请求已拒绝

管理员你好,敝人发现了这两个条目可以列为新条目推荐,可不可以代为编辑??

改革DYKC留言方式,每个条目讨论单独一个页面

目前的问题/问题背景:

  • 经常光临DYKC的用户,可能会发现有时候有两个讨论串完全一样,或者是自己的DYKC消失了,这种现象都是因为编辑冲突而起。比如说,一个用户在编辑第10章节时,管理员把第一个章节删除存档了,那么他编辑的内容将保存到原来的第11章节、后来的第10章节,这样就会把另一个DYKC提名覆盖掉。我相信@Cyril Yoshi前几天遇到的就是这个问题。
  • 另外,现时各类编辑都集中在一个讨论页面,主编和关心个别评选的用户,在不借助ping的情况下很难获知条目评选的最新动态(如修改意见等)。

草案:本人观察enwiki,无论那边的评选方式和我们的有何不同,他们的评选皆是放在Template:Did you know nominations的子页面下,如en:Template:Did you know nominations/Armorial of British universities。因此我认为本站可以引入类似方式,有点类似于N年前的特色条目评选。我不太清楚GFAN改版的原因,我认为这种方式对GFA可能小题大做,因为GFA的提名总是相对于DYKC少,也很少有短期内大量编辑,但是DYKC页有机器人,无论什么时候都可能会遇到上面提出的问题。看了一下存档,过往似乎没有类似讨论,故发起。

好处:

  • 避免编辑冲突导致无辜的提名被覆盖
  • 能及时获知某一评选的最新状态
  • 可以搭配js实现快速投票。这点在现时不是不能实现,但是各评审设子页面后将更为方便(参见元维基社群愿望单讨论)
  • 可以在各页增设DYK工具箱(现时也是可以实现,但容易导致排版错误)

坏处:

  • 机器人可能不好管理
  • (待补充)

不求此提案能够通过,只是听取一下各位的意见和吐槽。以上。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月11日 (二) 02:24 (UTC)

  • 又是DYK了,这次大概也能听听看会有什么新问题,直接(=)中立不多说了。怎么不先想过以下问题:
  1. DYK评选因为门槛低,所以较多人会申请DYK不是没道理的;如果又逢动员令(俗称DC)的话(像DC18这次就看到DYK提名数量约落在180个),评选太多了。难道这么多评选不会导致编辑冲突吗?抱歉,何时会编辑冲突没人知道。
  2. DYK结算主要是由管理员结算,并非所有用户都可以结算。
  3. 所谓的新的DYK机器人也不知道在哪,在Liangent-bot机器人坏掉后就一直都是手工处理,跟一般评选一样的做法不是吗?

还有,如果180个提名就不是得要有180个页面了?那要生多少空间阿?硬是要生空间的话,那么提名DYK的模式都得改改阿。另外,DYK也不是FA,是不是应该先问问为什么FA评选的时候要有什么FA的工具箱,但为何其他评选都没有?FA的工具箱在评选中也不常听到,所以实质作用仍然是个问号(也可能没有用)。若果坚持要为DYK加上什么工具箱,(-)反对,排版显然只会更乱而已。--Z7504非常建议必要时多关注评选留言2020年8月11日 (二) 03:30 (UTC)

    • 看了您的留言半天,又读不懂又气的头疼,不知道说什么好,这到底是什么东西?如果不会说人话的话不建议参与客栈事务。1.本提案就是要解决评选太多带来的编辑冲突啊???2.跟本提案有什么关系?3.Cdip150目前正是机器人手动处理,何不食肉糜?况且现在就讨论要不要加工具箱,跟机器人没多大关系吧(除非讨论到技术事务)4.不明白生空间有什么不好的,担心服务器过载?5.英维一直有DYK工具箱。况且加不加工具箱纯粹是后话,现在讨论的就一个问题,要不要把各个评选分开,6.如果您不想讨论的话您大可不用参加讨论,您这态度我都不想说什么。还有,发言之前多过过脑子,免的出现上次DC差点取消的惨剧。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月11日 (二) 06:09 (UTC)
    • 我想问您一个问题:您到底会不会说人话?Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月11日 (二) 06:12 (UTC)
      • 如果觉得不是人话那就不要理会阿,也只是就事论事说而已,维基百科也没说必须什么都要说对的,更别说一定要说“人话”。还是说连编辑某个页面都要预测别人何时也会编辑同个页面?大可认为发神经了。还有,如果在维基百科上,用户真能和机器人合为一体,作为同一账号用的话,以后不要提DYK的机器人也罢。DC取不取消,也和本讨论无关好吗?为什么就不能说DC造就出了DYK评选过多的问题?--Z7504非常建议必要时多关注评选留言2020年8月11日 (二) 07:33 (UTC)
  • (?)疑问:目前中文维基的提名通过后是直接存档至条目讨论页的,en则是直接在Template:Did you know nominations的子页面存档,如果在中维使用子页面进行评选的话评选结束后该怎么处理呢?是删除子页面后移动到讨论页还是用{{include}}之类的模板链接过去?——BlackShadowG留言2020年8月11日 (二) 05:37 (UTC)
  • 如果要改革DYK,我一贯建议是废除投票制,改用类似afd的共识制,排板也可以参考afd模式。—AT 2020年8月11日 (二) 08:50 (UTC)
  • 有新机器人再来讨论吧。--Temp3600留言2020年8月11日 (二) 13:25 (UTC)
  • (-)反对
  1. “避免编辑冲突导致无辜的提名被覆盖”:这理由放在3年前说些许还有些道理,然而早在3年以前本站的编辑冲突功能已足够“聪明”,即使您在编辑之时另一位用户修改了另一个章节,只要不是真的产生了冲突(e.g. 他新增了一行但是您的编辑有把这一行移掉的效果,之类的),一般不会引起冲突而是会自动合并。显而易见的是这个功能会随着时间的推移变得越来越强大(例如留言直接回复功能有望消灭对章节编号的依赖)。拆分子页面也越来越起不到防编辑冲突的效果,还增加了维护管理的难度。
  2. “能及时获知某一评选的最新状态”:感谢强大的User:Cewbot,这已然不是问题。

--Antigng留言2020年8月11日 (二) 13:54 (UTC)

好像这个是一个第三方编辑器Wikiplus的老问题(客栈的对话偶然发现一次这样的诡异问题),我认为需要fix的对象是不是搞错了?——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年8月12日 (三) 01:59 (UTC)
楼下可没有用w+,况且这问题跟w+没有关系。—Rowingbohe♫ 欢迎参与浙江专题 台州专题 2020年8月12日 (三) 09:09 (UTC)
  • 看不太懂提的方案会变什么样子,但编辑冲突的问题确实存在。我常遇到点了章节编辑结果进入另一章节的情况。--Yel D'ohan留言2020年8月12日 (三) 08:24 (UTC)
  • (+)支持:只要提案在技术上可行(例如机器人能否正确存档至讨论页、DYKC主页面要怎么显示和管理),我是赞成的,毕竟跳章节(点A进B)很烦,而我这个人又贪方便,再来哪天提名被吃掉的是我就糟了。支持是支持,不过恐怕帮不上忙,就交给提案者努力了。至于怕占空间的话,就看机器人能不能在条目上首页后,将评选页面的内容移至条目讨论页,再直接把评选页面给删了。这就好像GA如果被撤销资格,他在GA底下的子页面(就是上首页那个)就会被删除,同样的道理,如果这条目不再是候选之一(以存档完为前提),那么评选子页面大有理由删掉。以上纯为个人观点。--EzrealChen留言2020年8月13日 (四) 09:16 (UTC)

@Rowingbohe:“Cyril Yoshi前几天遇到的就是这个问题”,能否提供diff连结给我检查?--街燈電箱150號 开箱维修 抄表 检验证明 2020年8月17日 (一) 05:31 (UTC)

迷之操作,已解决。--东风留言2021年1月13日 (三) 15:23 (UTC)

下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

刚刚看到U:BookwithWikipedia:新条目推荐/候选移动到Wikipedia:提名DYK,有没有人要处理一下? --无心*插柳*柳橙汁 2021年1月13日 (三) 14:58 (UTC)


本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

编辑请求 2021-04-09

请求已处理。--东风留言2021年4月9日 (五) 14:49 (UTC)

请协助提名新条目。请在发布后记得将提名人改成我。。。(当然如果您觉得条目还不错,署上您自己的用户名也可以,投个提名人票就更好了)

==== ====
{{safesubst:DYKEntry/auto
 | article = 放射齿目
 | question = [[放射齿目|'''哪一目节肢动物''']]生活在[[寒武纪]]至[[泥盆纪]]期间,其口器牙列呈辐射状,曾因化石发掘不完整被命名为“奇异的虾子”?
 | image = 20191201_Radiodonta_Amplectobelua_Anomalocaris_Aegirocassis_Lyrarapax_Peytoia_Laggania_Hurdia.png
 | type = Biology
 | author = 
 | 理由 (不必簽名) = 已凉凉的[[WP:协作计划|协作计划]]第15篇作品。今日刚刚从Draft移动到条目空间。讨论页贡献记录不完整,请参阅编辑历史了解各编者的贡献情况。
 | nominator = {{subst:REVISIONUSER}}
 | timestamp = {{subst:#time:U}}
}}

--173.75.41.7留言2021年4月9日 (五) 14:42 (UTC)

完成--东风留言2021年4月9日 (五) 14:49 (UTC)

编辑请求 2021-04-10

请求已处理。--东风留言2021年4月10日 (六) 14:48 (UTC)

完成 --东风留言2021年4月10日 (六) 14:48 (UTC)

问题回报:新条目推荐候选里面的机器人似乎有点问题


当投票者用英文"{{support}}"投支持票的时候,机器人的auto voting counting似乎无法正常工作。抄送管理员@Cdip150,谢谢!--Tazkeung(CommentHERE) 2021年3月29日 (一) 05:15 (UTC)

未发现问题,参考Special:diff/64969563/prev#秘鲁死刑制度的点票,四票支持中含有一个{{support}}仍能如常给予批核。--街燈電箱150號 开箱维修 抄表 检验证明 2021年3月29日 (一) 06:00 (UTC)
好像是我对auto voting counting的逻辑理解有点偏差。-Tazkeung(CommentHERE) 2021年3月29日 (一) 07:38 (UTC)
@Cdip150:我曾经注意到,使用{{support|资瓷}}投支持票的时候,机器人未将其计入支持票的情况。Itcfangye留言2021年3月29日 (一) 23:53 (UTC)
在人手点票的时代我已经说过很清楚:规则讲到明只算“支持”和“反对”,写“资瓷”、“滋磁”、“返队”那些是会当成无效投票来处理的。--街燈電箱150號 开箱维修 抄表 检验证明 2021年3月30日 (二) 01:47 (UTC)
现在的规则是写“投票者可用{{支持}}{{反对}}{{意见}}{{建议}}等投票或作为引子来表述观点”,和你的表述似乎不符。{{support|资瓷}}仍然是{{support}}(或{{支持}})的一种使用方式,按规则应该是计票的。SANMOSA Σουέζ 2021年3月31日 (三) 08:16 (UTC)
@ItcfangyeCdip150SANMOSA Σουέζ 2021年3月31日 (三) 08:17 (UTC)
那如果有人来个{{support|反对}}((+)反对)是否又应该计呢?--街燈電箱150號 开箱维修 抄表 检验证明 2021年3月31日 (三) 08:24 (UTC)
还是看实际上使用的模板,因为现行规则如此,不然你就去提议修改规则。不过,如果真的出这种情况,不是应该先考虑一下他是不是在扰乱吗?这我认为是其他方针指引涵盖的范畴。SANMOSA Σουέζ 2021年3月31日 (三) 08:45 (UTC)
这就是规则理解上的问题了:“投票者可用{{支持}}”,但没有说可以在投票模板加参数{{支持|xxx}},所以当作不规则行为也不能说错。当然如果认为规则写得不够好,我不反对修改,但多年来的实际操作是的确是没有计算那些耍花样的票。--街燈電箱150號 开箱维修 抄表 检验证明 2021年3月31日 (三) 10:23 (UTC)
明确规则是好事。建议明确规定动用到自定义参数修改预设显示文字的模板不计票。SANMOSA Σουέζ 2021年4月1日 (四) 03:25 (UTC)
其实就写{{支持}}或{{反对}}很难吗?未明{{支持|滋磁}}甚至{{支持|反对}}的意义何在。DYK不是AFXD也不是UA,不需要抖机灵,乱七八糟的投票方式只会令不论是人工还是机械都一头雾水。--SW❀Dalniy coming soon 2021年3月31日 (三) 08:38 (UTC)
理应明定自订模板参数的投票无效。—— Eric Liu 创造は生命(留言留名学生会 2021年4月1日 (四) 04:44 (UTC)
已在WP:VPP处就此问题发起相关讨论,有讨论意愿者可以参加。--Tazkeung(CommentHERE) 2021年4月2日 (五) 04:27 (UTC)

提议对WP:DYKC的投票须知进行修改

下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

现行条文

投票者可用{{支持}}{{反对}}{{意见}}{{建议}}等投票或作为引子来表述观点

提议条文

投票者可用{{支持}}{{反对}}(或{{support}}{{oppose}})进行投票,动用到自定义参数修改预设显示文字的模板不计票。可用其他模板作为引子来表述观点

WP:VPT#问题回报:新条目推荐候选里面的机器人似乎有点问题中的讨论引申出来的一个条文修订提议。建议明确现行DYKC的投票模板,从而方便人工或者机器人的点票工作。

--Tazkeung(CommentHERE) 2021年4月2日 (五) 04:12 (UTC)

代增补一条。SANMOSA Σουέζ 2021年4月2日 (五) 05:07 (UTC)
(+)支持此提议。另外,建议增加{{Support}}{{Oppose}}写明于说明内(首字母大写不同),使叙述更加明确涵盖到此二模板的各种表示法。不过如果要考虑到点票作业方便,鉴于{{Support}}、{{Oppose}}为较泛用型的意见表达模板,建议可以仿照FA、GA评选,建立评选投票专用模板(比如仿照{{YesFA}}、{{NoGA}}的呈现方式,修改既有{{YesDYK}}、{{NoDYK}},使其做为DYK评选投票专用)。如此应可以增加点票作业程序的稳定性。--Bowleerin留言2021年4月3日 (六) 08:17 (UTC)
那么如果真的有意见或疑问,想要咨询主编怎么办?例如条目内文中出现“……于昭和二十年(1955年)创立”这样的年份错误,想要请主编确认到底是昭和二十年还是1955年。-游蛇脱壳/克劳 2021年4月3日 (六) 13:10 (UTC)
啊就(!)意见(?)疑问啊,这两个模板本来就不计票。—— Eric Liu 创造は生命(留言留名学生会 2021年4月3日 (六) 13:29 (UTC)
公示7日。SANMOSA Σουέζ 2021年4月10日 (六) 05:59 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

T: DYKEntry


T: DYKEntry 的 type 参数是怎么一回事?为什么会要求英文?为什么会要求“属culture类”这样的说明?是为了让机器人展示不同种类的新条目吗?谢谢! — XComhghall talk 2021年9月4日 (六) 00:28 (UTC)

是的,不过这个可以由管理员机器人填的,您可以把它留空,机器人会自动补上。--街燈電箱150號 开箱维修 抄表 检验证明 2021年9月4日 (六) 01:51 (UTC)
同问。我们在讨论中被要求使用中文,但这里的type却要求英文,方针自相矛盾。而且究竟存在哪些type在本页亦未见说明,令人困惑。--Luminoxius留言2021年9月14日 (二) 22:02 (UTC)

提议调整新条目推荐问题指南时效性描述(暂时性折中方案)

如题。目前新条目推荐(下称DYK)的问题指南建议“避免一些答案会随时间变化的问题”,这个部分时常会有人提出异议,认为问句只在短暂的一段时间登上首页却要确保答案永远不变实在是不合理。以前也有过相关讨论,不过最终没有达成共识,最大的阻力来自于Portal空间。不过目前不同Portal的DYK存档处,存档标准不同,有的按年存档,有的按月存档,有的甚至完全不分年月,要想在Portal这边统一恐怕不是易事,另一方面,Portal空间的DYK栏位未必能够得到及时更新,肯定也会有用户认为无需照顾Portal空间。

不过有一个地方是肯定会收录登上首页的每一条问句的,就是Wikipedia:新条目推荐的各个以“XXXX年YY月”命名的子页面,这些子页面按月来存档登上首页DYK栏位的问句(例如这个),但每一个子页面都完全没有注明各问句具体登上首页的日期(这点和英文版不同)。由此,出于技术上的原因避免答案在登上首页当月出现变化就显得非常有必要了。

故在此提出两种方案,第一种方案是强制所有问句必须确保登上首页所在的年月答案不会出现变化,当然需要考虑到跨月的情况,有些当月下半月提名的条目可能直到第二个月才会登上首页;第二种方案是仿照英文版,在“Wikipedia:新条目推荐/XXXX年YY月”里面按照日期进一步分类各个DYK,这样只用在登上首页的那一天答案不变即可。个人倾向于选第一种方案,因为第一种方案可以更好照顾到按月存档DYK的Portal。

至于是否确保“答案永远不变”,这个就仍旧维持建议级别。当然要彻底解决问句时效性的争议必然还是要对Portal这边下手,不过Portal这边要想制定一个能够得到充分执行的解决方案是不容易的,因此这个讨论我在标题上写了“(暂时性折中方案)”。--🔨留言2021年12月8日 (三) 05:05 (UTC)

其实对于可能水晶球问题,问题之前加个“截止XXX”的时间点就解决你提出的问题了。个人认为这是设置问题的做得不够好,与机制无关。--Nostalgiacn留言2021年12月8日 (三) 06:18 (UTC)
同意,建议在问题指南中加入这个建议。--Yangwenbo99 诚邀诸君参与自主隔离运动 2021年12月8日 (三) 06:23 (UTC)
用什么样的方式提问来避免时效性问题不影响个别用户对于问题指南时效性的部分本身的意见,他们还是会觉得用“目前”、“至今”更加顺口,而且他们也不认为照顾Portal名字空间重要,但是由机器人维护的“Wikipedia:新条目推荐/XXXX年YY月”存档是不一样的,所有通过的DYK问句都会被自动放在这里,这是过往相关讨论没有提到的部分(至少我暂时没看到有提到)。而且我的提案假若通过,个别情形理论上是可以允许“目前”“至今”,只要能够保证上首页当月答案没变就行,总好过要求永远不变徒增个别人心里的抵触,而且这样的技术性理由相对于“Portal的无注明时间存档”来说更容易接受。--🔨留言2021年12月8日 (三) 07:29 (UTC)
Portal的问题其实也不祇有DYK存档处,其实还要考虑Portal首页的DYK展示区,尤其是特别冷门的,像是Portal:澳门,对上六次内有澳门条目入选DYK都能数到2018年的“哪个寻欢胜地位于澳门葡京酒店,在2015年1月被司法警察局捣破?”,也就是说即使该Portal的首页能及时更新,问题都能放在首页三年之久。那么就算硬性规定Portal的DYK要按月存档来保证上首页当月答案没变,也不可能避免一些Portal的首页出现了“某些有时效性的DYK问句,当发生答案出现因时间而变化的时候,还没有新的DYK把它从首页挤下架”的问题。又或者说,即使要不顾Portal的存档问题,Portal的首页还是要注重。--街燈電箱150號 开箱维修 2021年12月8日 (三) 08:30 (UTC)
我知道Portal的一些情况致使问题指南增设时效性方面的限制,也知道一切针对此限制的修改需要考虑这部分。然而另一方面的问题是,近些年来我也遇到过不少提及到这条限制的时候,要费些口舌和对方理论,或者说对方认为完全没有采纳必要而不理睬的情况,就是因为当前这条限制主要是为Portal服务,但是Portal的因素对于某些用户来说,仍旧欠缺一些说服力,所以我在这里提及到“Wikipedia:新条目推荐/XXXX年YY月”这个东西,就是在想如果说问题指南时效性方面描述理由的时候不止提到Portal,还额外提到一些就算是他们也会觉得真的属于不可抗力或者说没有办法的技术问题的因素,至少以后我要求修改那些答案在可预见时间内容易发生变化的问句,可以少费一些口舌解释。--🔨留言2021年12月8日 (三) 11:50 (UTC)
一如以往看法,DYK应该废除提问形式,比照日维直接展示的形式更佳,这可以省却思考提问的时间,也可以避免有关于问题不当的纷争。--AT 2021年12月8日 (三) 09:56 (UTC)
反对DYK问题时效要求,只要上首页时问题没有错就行了。“截至”保险?如果有时光机怎么办?本来很生动的问题加个截至(毫无意义的日期)后就变得一言难尽。--7留言2021年12月8日 (三) 14:21 (UTC)
如果只要上首页时没有错就行,那么上到Portal主题首页的DYK展示区变了有错也都行?时光机是不可能的吧。--街燈電箱150號 开箱维修 2021年12月8日 (三) 15:30 (UTC)
  1. 不管是不是完全反对这个时效性要求,有一点是肯定的,就是当前的DYK机器人存档机制导致技术上必须至少确保问句答案在登上首页的当月不会出现变化(换句话说这相当于最低要求),如果连“Wikipedia:新条目推荐/XXXX年YY月”都不想照顾,建议你提请修改机器人存档机制,要求机器人维护的DYK存档处仿照英文版标注具体日期。
  2. 加上“截至XXX”绝非解决问句时效性问题的唯一方案。有时通过调整提问方式,既能避开时效问题又能保证问句显得很自然。
  3. 至于Portal首页,一定要照顾到的话,除了在问句前面或后面强制标明具体上首页的日期,别无他法,但Portal的冷清导致就算有解决方案,也要面对难以执行的问题。我就建议新增一个专门给portal用的dyk模板,要求必须填写各个dyk的日期。--🔨留言2021年12月9日 (四) 01:15 (UTC)
黑衣人不是说了,1500年前人人知道天圆地方,500年前人人知道太阳绕着地球转,(15分钟前你知道时光机是不可能的。)我个人认为Portal那里真不是DYK应该考虑的问题,Portal转引也完全可以注明DYK登上首页的日期(即只说明在那一天是对的)。很多事情、甚至很多条目的价值就完全源自时效(不是新闻那种)。Portal要是这么要紧,对时效如此敏感,那条目内容更可能出问题,岂不是个个要找业内专家来把关?--7留言2021年12月15日 (三) 13:56 (UTC)
你们慢慢争论,然后整个讨论又变成没有共识,最后你们什么事情也做不到。我对Liu116的提案与AT的替代提案本身没有意见,但我对于Cdip150与Jarodalien的讨论方式的恰当性与有效性有很大程度上的怀疑。--Sanmosa Immortal 2021年12月16日 (四) 01:20 (UTC)
其实对于Portal我还想到其他的一些方案:要么Portal的DYK栏位不再显示问题,只显示哪些条目何时上过首页新条目推荐栏位,要么Portal的DYK栏位干脆全部都废掉,要么干脆用AT君的方案,即直接仿照日文版那样。当然这些方案可能不会得到什么支持。去除时效性限制也不是照顾不到Portal,不过一切相关方案的执行都是比较困难的,一方面工作量大,二方面也不能保证后来更新的用户会用什么格式。但这不代表要彻底放弃改变,因为只要一天不改变,就总会要因为这个问题在评选区和其他用户争论,我是有这种经历的,我也不希望再遇上这样的事情。所以如果有更好的解决方案,还希望各位能提出来,正如Sanmosa君所说争论来争论去到最后什么也做不到。--🔨留言2021年12月16日 (四) 02:01 (UTC)
如果在Portal展示区注明登上日期,事实上还不如直接在问题上指明时间。而且,问题在登上首页当日会不会出现时效变化?其实我们也未能百份百确定。另外,DYK还有按日存档的,如果当日未完就发生变卦,怎么办?这种情况虽然是有些极端但还得要考虑。--街燈電箱150號 开箱维修 2021年12月16日 (四) 05:23 (UTC)
谁都没法保证他的DYK问题永远正确,不信你问问以下几条DYK的提名者:[开玩笑的]
某条1500年的DYK:
某条690年正月的DYK:
某条十亿年前的DYK:
 ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月19日 (日) 08:51 (UTC)
汉语本来就不讲究精确,强行讲究不过破坏汉语生态。条目内容会根据时代变化,portal没问题,偏偏要在DYK问题上讲究永远正确实在有点没事儿找事儿。某个问题答案可能若干年后不唯一,那又有什么关系?DYK问题就是个历史存档,而且上面说了好多事情本来的价值就在于时效,广岛和长崎这两个大家都知道他们有什么特殊的,如果维基百科连这种事情都还要考虑时效,说截至什么时候哪里发生过核武攻击,那要不要考虑未来可能核武攻击已是家常便饭,全世界绝大多数城市都有过,届时两地失去“卖点”,所以还是别问这个了,改成问“XX名人出身哪个日本城市”?这也太可悲啦。--7留言2021年12月19日 (日) 12:21 (UTC)
那你对Chinese language的理解可能与我们其他人有这一定程度上的偏差。--Sanmosa Immortal 2021年12月19日 (日) 14:40 (UTC)
我想强调一点,就是提这个话题的目的是针对问句时效性限制争议提出一个阶段性解决方案。我知道有的人对于这条限制有意见,这点以前的讨论提过不少,既然是这样就更应该着重于具体怎样解决这个问题。现阶段机器人有在按月存档DYK,照顾这个按月存档的DYK存档处限定问句必须上首页当月答案不变合情合理,就算不合理你也可以提请仿照英文那样。我也没忽略过Portal,不过本站三百多个portal,就算有好的解决方案一个一个去修改也不是那么简单,所以我说这是暂时性的方案。也许这次很难达成共识了,不过如果后续的讨论都像现在这种样子的话,到头来什么都不会变,不满时效性限制的人也只能继续这样不满下去。--🔨留言2021年12月20日 (一) 01:31 (UTC)
DYK的问题只要登上首页期间正确即可,个人认为无必要追求永久正确,也不喜欢为此在问题上加上“截至何时”。DYK存档与主题页展示的DYK在问题后方标注日期即可,或者在页首提示问题仅保证在登上首页期间正确、唯一,并指引读者到条目讨论页查询该条目登上DYK的日期。--Sanchytriomycota🧬 2021年12月20日 (一) 01:40 (UTC)
个人认为有必要追求永久正确,谁能保证在登上首页期间就不会变化?如果首页还在展出的问题发生了时间变化而不正确,想改也改不了。--Maccomcre留言2021年12月20日 (一) 04:09 (UTC)
注意看我的提案是强制问句至少保证登上首页当月不变,能做到这一点的问句,通常能够“保证在登上首页期间就不会变化”。--🔨留言2021年12月20日 (一) 05:30 (UTC)
(!)意见,就算要置Portal于不理,仅要求问题答案当月有效在操作上显然也是不可能的。注意的是一个条目即使投票完了并不会即时登上首页,而是还要多等一段时间才上,投票完后与上到首页之间要等多久时间,完全取决于在它之前还有多少积压(先不计因故搁置的,最长记录试过15天);如果条目出现门槛上的问题而被暂时搁置,可能则要等更久(如计因故搁置的,最长记录试过逾3个月);是故一个条目会在什么时间登上首页也是不可确定的。而由于登上首页的日期不可确定,试问叫人怎样确保至少当月有效?因为都不能确定会在哪个月上到首页。这下更遑论只需在登上首页当日有效的问答,因为连哪一天上到首页都不知道,怎样能百份百保证上首页当日还有效?所以只有永久有效的问答才具有操作性。--街燈電箱150號 开箱维修 2021年12月20日 (一) 12:11 (UTC)
如果要顾虑这个的话,可以要求问句在开始评选后保证60天内不变,假设一篇条目在某月中旬开始评选,投票期达到一周,然后又要排队等上大约一周,刚好被排到下个月的月初才上首页,整个评选横跨两个月份,设定60天足够满足绝大多数情况,极少数被搁置的讨论基本上需要人工确认,问句也可以在这个时候再行评估,本来任何限制都需要足够的执行力。我当然觉得永久有效更好,不过很显然这条限制是所有DYK问句限制当中争议最大的,而现有的理由真的说服力不够,容易给限制的实际执行带来困难。--🔨留言2021年12月21日 (二) 02:03 (UTC)
那各做各事,各找各妈呗。要坚持“永久正确”的也由他,拒绝的如果真出现上首页时“不正确”,给人提出要么撤下来要么修改(就像内文一样)。阿波罗11号是人类首次登月,谁知道500年后会不会有新研究成果说现在的人类已经是地球上第N个循环世代,早就不是第一次了,月球背面还有纳粹基地呢。位于纽约港的哪座巨型塑像是自由和美国的象征?N年后自由女神不复存在,或是美国已经不复存在,甚至上首页当天有人开飞机把她撞了;尼德兰画家罗希尔·范德魏登估计在1460年完成的哪幅女子肖像现藏美国国家美术馆,评论认为能与任何流派的女子肖像一较短长?如果突然有最新研究成果说这画根本就不是XX的作品,或者根本就是现代伪作,或者里面画的其实是男子扮的,评论风向马上改了说这什么垃圾玩意儿;真要“永远正确”,九成九的条目都有办法让你问不下去。--7留言2021年12月21日 (二) 03:42 (UTC)
要知道等待排队的时间理论上是无上限的,所以60天理论上并没有解决问题。而针对因故搁置的条目,本来就已经因为门槛的事宜而被折腾了一番,最后人工确认放行时又要再折腾一次问句,费时失事,所以我也是不希望届时又再评估,投票结束后才评估问题本来就不见得是什么好的事情(虽然现在偶尔还有发生在正常的投票里),本来就应该要避免,而不是让它有更多机会发生。针对于上首页时不正确要撤下来或修改的问题,从过往的经验都知道,大部分都没能在展示完毕前得到修正或撤下,首先是管理员们不是时时刻刻都在线,二来是被发现有问题的时候往往是已登上了一段时间,多半还未等到管理员回来处理就已经展示结束了,所以说“给人提出要么撤下来要么修改”,其可操作性非常低。--街燈電箱150號 开箱维修 2021年12月21日 (二) 07:49 (UTC)
那就当成和条目内容一样(不)处理。非要时效,自由女神像倒塌、美国不复存在都只是时间问题。典范条目同样不能保证“永远正确”,那又有什么关系,要说这种不可操作,那真按时效来讲根本没有任何问题能成立。--7留言2021年12月21日 (二) 14:03 (UTC)
所以问“1886年哪个巨型古典主义塑像在美国落成?”不就已经不用担心将来会倒塌的问题了、“1776年7月4日哪个国家宣布独立?”不就已经不用担心将来会灭国的问题了,趣味都还是次要啊。FA与DYK的展示程序本来就已经有大不同,FA能确切知道何月何日会上,但DYK不能,两者是根本不可类比的。--街燈電箱150號 开箱维修 2021年12月21日 (二) 15:24 (UTC)
趣味如果次要,何必还要问题。我的意思不过是条目内容都可能错,执着DYK问题“永远”正确实在不可思议。我无法接受这种强制,那以后凡是我提名的,如果有“时效问题”,烦请不用修改,直接别通过吧。--7留言2021年12月21日 (二) 15:33 (UTC)
纯粹是猜答案,从来没说过一定要有趣地去猜,至少大家不会因为问题欠缺趣味就给人打个 问题不当。条目内容有错是另一层次的问题,但绝不是毋须执着的合理理由。--街燈電箱150號 开箱维修 2021年12月21日 (二) 15:52 (UTC)
OK,看来上面应该要争论到不知何时何日了。为了尽可能促成共识,我附议AT替代案,DYK可改为直接展示节选条目内容。Sanmosa Immortal 2021年12月26日 (日) 04:26 (UTC)
如果AT的方案能够得到更多人支持的话,那我也强烈支持。可惜以当前社群现状来说很难通过。--🔨留言2021年12月27日 (一) 08:52 (UTC)
既然我正式附议了AT替代案,那我就走7DAYS程序,7日内无新留言我就送去公示(因为没有人对“DYK应该废除提问形式”的提议表示反对)。有progress总比没有progress好。Sanmosa Immortal 2021年12月27日 (一) 13:11 (UTC)
个人认为这样的大改动显然需要留更多时间讨论,确保能收集更多意见,更何况这个替代案现在连更具体的细节都没有,建议等这个话题存档后再另开一个新话题正式提案。--🔨留言2021年12月28日 (二) 01:10 (UTC)
不是很支持废除提问。另外给出一个已经不满足“永久正确”的DYK问题的真实例子:
 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月1日 (六) 11:55 (UTC)
所以以后别问这种问题了,如果要强调曾经不存在,标明是在什么时间曾经被灭就好,例如:“哪个曾于2001年被推翻的国家是由塔利班所统治?”--街燈電箱150號 开箱维修 2022年1月1日 (六) 13:04 (UTC)
当时估计没人想得到塔利班会卷土重来。所以这还是有赖提问者自行察觉可能的漏洞,最好是纳入那些最不可能的情况来考虑。—— Eric Liu 创造は生命(留言留名学生会 2022年1月1日 (六) 18:49 (UTC)
展示内容也可能过时吧?现任中华民国一、二级行政区行政首长列表这样的条目如何展示。 绀野梦人 肺炎退散 2022年1月4日 (二) 02:40 (UTC)
这种情况下,列表内容本身随时间变动而变动,因此只要能确保列表的内容能适时更新,我觉得问成“现任中华民国一、二级行政区行政首长有哪些人?”是没问题的。--Sanmosa Immortal 2022年1月4日 (二) 02:55 (UTC)
也就是这类条目提问反而比展示内容不易过时。用哪种形式都可能有时效问题,解决时效问题还是每则存档注明上首页时间更有效。 绀野梦人 肺炎退散 2022年1月4日 (二) 11:19 (UTC)


2022年5月

@范博2004请问为何两度将我的候选提名删除?另想请问@Cdip150遇到这种情况如何处理?[1][2]----Koala0090留言2022年5月10日 (二) 14:08 (UTC)

@Koala0090? 我没有啊。我最近对于我自己所创建的页面也总是莫名其妙的变成其他版本,显示为我本人编辑。——范博 · · 2022年5月10日 (二) 14:26 (UTC)
@Cdip150 这种卑劣的行为我绝对没有干过。——范博 · · 2022年5月10日 (二) 14:32 (UTC)
已提交至Wikipedia:互助客栈/求助#非本人编辑问题。——范博 · · 2022年5月10日 (二) 14:58 (UTC)
已提交至User talk:DinoWP#冤枉!冤枉!,此管理员是我的导师。——范博 · · 2022年5月10日 (二) 15:00 (UTC)
我不是管理员啦w--Talk · DinoWP · Sign 2022年5月11日 (三) 11:46 (UTC)
另外,

我想这源自您遇到的Wikipedia:互助客栈/技术/存档/2022年5月#光标问题,画面上呈现的语法高亮的内容和实际内容不相符。近期在编辑某些页面时有遇到这种问题(好像是Lua模块或者common.js,修改后内容错位)。在问题得到解决前,建议避免使用2017版源代码编辑,或者多加预览差异。--YFdyh000留言) 2022年5月11日 (三) 09:39 (UTC)

--Talk · DinoWP · Sign 2022年5月11日 (三) 11:46 (UTC)

非本人编辑问题

维基百科讨论:新条目推荐/候选,产生了如下争议。 User:Koala0090所提出的提名根据历史版本显示被我两次删除,而这两次编辑并非我所为。如果这两次编辑确实出自我本人之手,我甘愿承担一切责任,包括被基金会永久封禁。请问这种情况应该如何处理?我应该怎样做才能避免这种情况发生?谢谢。 p.s.:我在我自己创建的条目中也发生过一次这种情况。--——范博 · · 2022年5月10日 (二) 14:48 (UTC)

Help:编辑冲突#不容易发现的编辑冲突。--Xiplus#Talk 2022年5月10日 (二) 15:14 (UTC)
@Xiplus:并没有。而且除了投票外,我绝不会修改甚至删除其他人的候选提案。——范博 · · 2022年5月10日 (二) 15:25 (UTC)
您是否直接编辑整个页面而非编辑单一章节?--Xiplus#Talk 2022年5月10日 (二) 15:27 (UTC)
在事发的dyk没有。——范博 · · 2022年5月10日 (二) 15:30 (UTC)
如果没有同时编辑多个段落的需求,就尽量使用章节编辑功能。--Xiplus#Talk 2022年5月11日 (三) 07:41 (UTC)
已将Special:滥用过滤器/182设为警告。--Xiplus#Talk 2022年5月10日 (二) 15:25 (UTC)
@范博2004:我想这源自您遇到的Wikipedia:互助客栈/技术/存档/2022年5月#光标问题,画面上呈现的语法高亮的内容和实际内容不相符。近期在编辑某些页面时有遇到这种问题(好像是Lua模块或者common.js,修改后内容错位)。在问题得到解决前,建议避免使用2017版源代码编辑,或者多加预览差异。--YFdyh000留言2022年5月11日 (三) 09:39 (UTC)
遇到过这种灵魂编辑事件……--Kethyga留言2022年5月12日 (四) 05:11 (UTC)
这个是ve的问题,跟lua一点关系也没有--SunAfterRain 2022年5月15日 (日) 13:09 (UTC)
可视化编辑器?出问题的编辑用的是2017版源代码编辑,我上文遇到的也是源代码编辑。--YFdyh000留言2022年5月15日 (日) 22:36 (UTC)

提名的“马尼库尔赛道”遭异常删除

7月21日晚上我编辑并提名了马尼库尔赛道条目。随后就在别人的编辑时被删掉了。请问是技术故障、手抖误操作,还是怎么回事?请求恢复提名。--超级核潜艇留言2022年7月22日 (五) 03:40 (UTC)

@超级核潜艇是未妥善处理的WP:编辑冲突这种),已通知当事人。-- 今晚 我想来点 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鲜果茶☕](☎️·☘️2022年7月22日 (五) 09:12 (UTC)

DYKC灌票问题

8月20日,u:A1Cafel在DYKC 5分钟内投下39张支持票,不知社群对此有何看法。Fire Ice 2022年8月21日 (日) 15:05 (UTC)

DYK有别于GA/FA之类,只要条目格式长度来源大致合格便可。也可能有部分是信任票,即是某些用户的出品质素一向稳定,没有太大问题,这类条目不用细看便可支持。--14.136.254.156留言2022年8月22日 (一) 00:47 (UTC)
5分钟投下39张支持票,相当于每投下一票只需要7.7秒。我不认为如此迅速的投票速度是基于阅览这些条目之后,可能导致DYK不具备应有质量。因此持(-)反对态度。--  2022年8月22日 (一) 01:40 (UTC)
好像很久远就有类似的问题。如果针对此例的话,可以检查下这些DYKC中的条目有没明显的问题而没被投票者注意到,作为反驳和质疑的依据。否则没啥好方法阻止,或者善意对待,不能排除人家一次过看完全部后再一次批量推票。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月22日 (一) 01:59 (UTC)
假设前面投支持的都负责任的话,就不能指望找到条目明显的问题;假设前面投支持的都不负责任,那这就是比灌票更大的问题。Fire Ice 2022年8月22日 (一) 02:30 (UTC)
对于后者,好像记得有个案例,好像被当破坏处理了(?),对于前者,那就没啥事,正常操作,难道还要限制投票速度?——Sakamotosan路过围观 | 避免做作,免敬 2022年8月22日 (一) 03:13 (UTC)
dyk你水我我水你不是常识?都2022年了为什么还有人信dyk?。->>Vocal&Guitar->>留言 2022年8月22日 (一) 04:02 (UTC)
不如学习英维的共识制。--210.3.157.159留言2022年8月23日 (二) 01:19 (UTC)
为免被认为使用IP傀儡,我声明一下,上述发言是我发布的,当时有点wp:维基中毒,就用js脚本强制禁止自己在一段时间内登录,所以用IP留言,但该IP之前的编辑不是我做出的。--——🦝Procyon rolandae Luo, 2022 「我々は堅く同志小林の血路に沿って前進し握手するのだ」留言贡献 2022年8月26日 (五) 13:39 (UTC)
这样也可以投诉,真是没事找事干。--A1Cafel留言2022年8月22日 (一) 04:09 (UTC)
您倒是回应一下上面的假设啊,做戏也要做全套嘛。->>Vocal&Guitar->>留言 2022年8月22日 (一) 04:12 (UTC)
好奇怪的回应……这是不否定自己的过速行为?--  2022年8月22日 (一) 04:30 (UTC)
每个人有属于自己的阅读方法,我喜欢阅后才投票你管我?--A1Cafel留言2022年8月22日 (一) 09:02 (UTC)
明白了。恕有冒犯。--  2022年8月22日 (一) 09:56 (UTC)
我也会一次看完多个条目后再一次投票。此举没什么问题。-KRF留言2022年8月22日 (一) 09:52 (UTC)
  • 奇葩社群在安倍晋三陶渊明的DYK时都已经对7天问题表示有争议了,怎么都没人提这个?再次强调,以后DYK应该可以考虑改名叫做“Wikipedia:条目推荐/候选”(英语简称不知道叫YK合不合适),“新”(D)可以拿掉了。反正水票问题果真又有人再次提出来了,一点点都不意外。--Z7504非常建议必要时多关注评选留言2022年8月22日 (一) 10:04 (UTC)
这也太赌气话了,DYK对应原来英文的话就是“Did you know...”(也就是“你知道吗?”),所以才会以问句式作为引子,而且可能早期就是为了让新条目有更多链入和曝光度的作用。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月22日 (一) 10:13 (UTC)
是Did you know没错,但可能未来连英文简称DYK都应该要改了或者直接删除简称(完全不符合“条目推荐”的英文,但若用AR又和Wikipedia:已删除内容查询撞名)。表示早期的做法用于现在显然已不符合事实,因为已经不被读者信任了,所以上面有人说不相信DYK也是对的。而且DYK问句总是要以唯一的答案做标准怎么也没人提出质疑,只针对灌票问题?现在完全连链入和曝光度的作用都没有了好吗?而且意义在哪,只是为了抢首页每天动态热门的前10名?那几率也很低好吗?个人认为以后看谁有能力再推出一个新的英文简称吧,不然都撞名了。--Z7504非常建议必要时多关注评选留言2022年8月22日 (一) 10:20 (UTC)
赌气的话那就没什么好说了,也没必要讨论其他杂七杂八的重新定义项目名称了。水票问题在老早之前(或者说WG还在的时候)就讨论过了,本质无解,是DYK的一部分,不爽不要玩,如果短时间内对一堆有问题的条目水支持票的,那才是问题,如果不是的话,那就不是问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月22日 (一) 12:39 (UTC)
从以上的回答就知道根本永远活在过去(WG时代),不可能进步且以后还有可能被拿来讨论的问题还是别说了吧?不爽真的可以不要玩,因为这社群仍然不想把这种7天期限已经知道有Bug的问题废除嘛,已经都有安倍晋三和陶渊明的前例了还是这样吗?全都是可悲事实。这种DYK无法说服人就直接说了吧,反正维基百科跟其它百科来比,刻意搞一堆评选的花样也没有比较有优势。请问读者要的是查询资料还是要天天看新条目评选?--Z7504非常建议必要时多关注评选留言2022年8月22日 (一) 13:54 (UTC)
现阶段来说,条目没质量问题,这样批量推支持票有没问题?没问题。但这种做法好不好,看得出,有人很不满意。对于我来说,没所谓,不过非要搞成像FA、GA那样按着单子来勾勾拖上好几天的“评选”还这样来拖慢投票速度,有没必要?正如前面所说,DYK的原始作用是什么?——Sakamotosan路过围观 | 避免做作,免敬 2022年8月23日 (二) 02:06 (UTC)
看了你提的两个例子,大概明白,你很介意“新条目”这个问题,因为这两个条目的创建时间不新,只是比之前扩充了就可以拉取跑“新条目推荐”。如果这么揪字眼的话,干脆跟回en的“Did you know”,直接用“你知道吗”作为这项目的命名了,就不用强调条目的“新”了,无论是新创建的完全重新的大幅度扩展旧有的,都能参加。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月23日 (二) 02:12 (UTC)
至于连续更新期可以“耍花样”(只要保持编辑时间点不中断超过7天就算是连续编辑期,这段时间的更改统一计算),当时允许这样处理是考虑部分编辑在条目上“原地施工”而且“现充很忙”,可以这样更好地照顾他们和计算编辑期、变更量。当然对于我来说,我的确不喜欢这样写法,要么全新条目一次过推上,要么已有条目先另开沙盒改好后再一次过追加在推上,推上的条目应该是已经基本完备的,不应该依靠这种“耍花样”的涓流修改。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月23日 (二) 02:24 (UTC)
了解一下你维最近又更新了什么有意思的条目,这也是有这种需求的嘛。Fire Ice 2022年8月22日 (一) 16:21 (UTC)
两点这样说好了:第一,这种说法表示只要在条目候选有提名的话就知道了,与是否有灌下支持票的水票也是无关;第二,还可以用Special:最新页面这个管道,基本上也不见得要提名。以前也说过了,不是所有新的条目都适合提这个“条目推荐”。试想,“新”这个字以后就可以考虑移除了,上面已经有很明显的举例了,就是看这独裁社群怎么想的。那么 不合要求的理由真的还适用在“7日内,至少有一次重大修订期的结束时间”吗?可想而知。--Z7504非常建议必要时多关注评选留言2022年8月22日 (一) 17:29 (UTC)
  • 推定善意。DYKC没有规定每投一票前只可先查看一个条目,用户可能把DYKC上有兴趣的条目都看过了,才开始投票程序。而且在DYKC的条目取得4票刚刚过关的占多数,只是短时间内投多票是没有问题的,除非短时间内对大量明显不符合资格的条目投支持票才是问题。--Uranus1781留言2022年8月22日 (一) 11:21 (UTC)
“除非短时间内对大量明显不符合资格的条目投支持票”这句倒是真的,所以可以推断出假定善意变相成恶意扭曲,属于维基百科根本无法解决的Bug嘛,在安全投票时就已经强调过维基百科现在就是一个标准的“Parkinson's Law”了。--Z7504非常建议必要时多关注评选留言2022年8月22日 (一) 11:25 (UTC)
这社群现在除了Cwek有极大意见以外还有谁对这个“条目候选”有意见的,最好直接讲出来别闷在里头吧。上面对“条目候选”提出的就是事实,难道还要“有中生无”?果真是自欺欺人的独裁社群没错。要不然光是说狂灌支持票也没用,这种问题还需要讨论(的必要)?--Z7504非常建议必要时多关注评选留言2022年8月23日 (二) 11:43 (UTC)
除了Z7504有极大意见,突然跳出讨论主题(短时间投票的问题),蹦出一个“条目候选”这样的红鲱鱼,这样走题的还生闷气的,爱理不理。至少正题,我觉得不太好但没规则上的问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月24日 (三) 00:48 (UTC)
那下次去别的地方大量投支持票的时候就别说有问题啊,神经、互相矛盾的独裁社群。说是“条目推荐/候选”难道不是吗?安倍晋三和陶渊明的例子到底有没有看懂啊?难道这些都还称得上是“新条目”?果真是自欺欺人,睁眼说瞎话的独裁烂社群,可悲。--Z7504非常建议必要时多关注评选留言2022年8月24日 (三) 12:23 (UTC)
我说过有问题吗?按照规则的话,没问题啊,只是观感不好罢了。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月25日 (四) 00:56 (UTC)
DYKC和FA/GA是有所区隔,DYKC属于起始及近期有较大的更新,或者条目仍未尽完善,但只要在可供查证及符合关注度要求,在下认为也适合安排放在首页的,这样也可鼓励用户作出更多参与,对百科的发展有正面的帮助,对于新用户或较少创建条目的旧用户,DYKC也是熟悉条目编辑要求的途径之一。关于旧条目不符合“新”条目的议论,以前确实只有全新创建的条目才符合DYKC的要求,但后来因为希望鼓励用户扩充旧条目,所以也纳入DYKC评选,这做法亦正好回应如上面【创建了条目却没有维护条目】的问题,为更新旧帖目提供动力,只是DYKC评选没把“新”字去掉。DYKC并非很容易便可通过,参与评选的用户也不多,观乎当前的WP:DYKC大部分通过的都是仅仅4票,6票以上便是高票通过了。与其混客栈进行不太可能有符合各方期望的议论,还不如多点参与DYKC、AFD等实务。--Uranus1781留言2022年8月25日 (四) 04:36 (UTC)
“5分钟内投下39张支持票”并不代表“5分钟内审阅39个新条目”好吗?“5分钟内投下39张支持票”的人究竟是花了多少时间审阅这39个条目呢?短到5分钟以下,长到合计15小时以上(不算中间吃饭、睡觉、休息等等的时间),都有可能的。如前面先进所言,可以全部审阅完,再一起投票的。没有规定须投完前一个条目的票,才能继续审阅下一个条目吧!?“5分钟内投下39张支持票”没有问题,“5分钟内审阅39个新条目”才有问题。但如何知道人家花了多少时间审阅条目呢?-游蛇脱壳/克劳 2022年8月23日 (二) 22:25 (UTC)
那如果确定没有规则上的问题,除非是投下明显有问题的条目,不然下次去别的地方短时间内大量投支持票的话就别说有问题啊。请问当时FL的评选期又是为什么要延长投票期限?不就是因为没什么人要投票吗?变到最后就是:“灌票也不是不灌也不是”。独裁烂社群,讲话似乎都不带逻辑的,只好标示重点了,连讲个东西都要翻存档也真麻烦。--Z7504非常建议必要时多关注评选留言2022年8月24日 (三) 22:45 (UTC)
对投票速度有意见的,请对准Fire-and-Ice喷,谢谢。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月25日 (四) 00:56 (UTC)
(!)意见,我倒是有个可能讨人厌的想法:把投票区全部移到条目底部或条目讨论页进行,那至少可以确保投票者有进入过条目才投票,当然有没有仔细看那就是后话了。--街燈電箱150號 开箱维修 抄表 检验证明 2022年8月25日 (四) 14:44 (UTC)
前者恐怕窒碍难行(就算是其他内容评选也不适合这样做),后者则或许不会跟现状产生多大区别。说到底还是看投票者的心态如何,有没有打算认真审阅条目。—— Eric Liu 創造は生命(留言留名学生会 2022年8月25日 (四) 15:08 (UTC)
我觉得上面某几位再长篇大论,也改变不了你维条目评审沐猴而冠问题,因为他们提不出解决方案,一如过去15+年的社群;就连Temp3600的改革也半途而废。我也怀疑你维有没有足够的人才来推行英文版DYKC的互审制。说起街灯的方案,我想起了很久以前条目下面会有一个评分工具让读者打分,但后来不知道是因为什么原因没了,说不定从读者的角度做评审会比现在这样好。不过我也开一下脑洞:虽然我说过,我想独裁也独裁不了,但是某人觉得我们独裁嘛,好哇,干脆剥夺普通编辑的投票权,只容许我们这些能写条目的人圣心独裁,决定以后推荐什么条目上首页。然而就跟老人区构想一样,基金会/社群看来不会喜欢这个主意。--春卷柯南-发前人所未知 ( ) 2022年8月25日 (四) 15:21 (UTC)
难道还要举例吗?白鲟也是2008年创建的条目却还是提DYK,请问就算灌票问题真的解决了,维基百科到底有没有要把“新”改掉了?说你们独裁社群刚好而已啊,又不想认真思考是否改名,这种东西完全举例不完嘛。--Z7504非常建议必要时多关注评选留言2022年8月26日 (五) 10:39 (UTC)
不要混淆视线。到底除了你和你的朋友们,还会不会有读者点进去DYKC,然后抬杠说:“噢,这里咋会有不是最近创建的条目?这就该改名嘛。”每天造访DYKC的人次就连首页造访人次的1%也没有,也就比编辑团队的人数大三到四倍。说白了就是虽然名不符实,也不会影响绝大多数读者的阅读体验,和条目评审质素差的问题更是八竿子打不着。反正我是不打算继续回应这个新制造的问题(但如果社群真的想不到更有用的事情,要讨论的话,或许会比这个容易一些)。--春卷柯南-发前人所未知 ( ) 2022年8月26日 (五) 16:14 (UTC)
认同,就是红鲱鱼。至少在投票速度上,除非找到投票意见与条目不对称而质疑其投票质量之外,没有规则上能管治的方法,至少规则上没问题。至于DYK的名称与条目项目的历史不对称,已经陪着吹水吹得够多了。——Sakamotosan路过围观 | 避免做作,免敬 2022年9月1日 (四) 09:05 (UTC)
根据Wikipedia:讨论页指引#markup清理不当文字特效。--Xiplus#Talk 2022年9月3日 (六) 04:12 (UTC)
路过,我认为“5分钟内投下39张支持票”是否构成“(灌票)问题”的前提是他在进行“投下39张支持票”的操作前是否已看过全部的相关条目。如果他是在看过全部的相关条目后才一口气投票的,那他就算用单一编辑投下39张支持票也完全没问题,毕竟不同人有不同的习惯。Sanmosa Királyunk s a közhazát 2022年9月13日 (二) 02:15 (UTC)
你们尽可以信所谓看完三十九个条目后一次性投票,反正我不信。Fire Ice 2022年9月15日 (四) 07:42 (UTC)
@Fire-and-Ice:所以A1Cafel到现在还是没就这件事作出任何的回应?Sanmosa Királyunk s a közhazát 2022年9月15日 (四) 10:40 (UTC)
回应就是看完39个条目再一次性投票啊。Fire Ice 2022年9月15日 (四) 13:38 (UTC)
不好意思,3天没看,现在回应一下。既然这真的是他的回应,那我们大可以看看他以前是否同样地有在几分钟内投下几十张票的操作,如果有的话,那可能可以说明这确实是他的习惯(虽然一口气看完39个条目实在有点夸张,就算是一目十行,这工作量也有点大,我略看10个条目都感到吃力)。Sanmosa Királyunk s a közhazát 2022年9月18日 (日) 14:27 (UTC)
9月16日是类似的,9月10日、4日、1日,7月22日等也都有一次投挺多。以9月1日为例,尽量多算是25分钟(不计自提一份DYK、一份优良条目评选的用时,约1~20分钟),投下32票无意见支持。--YFdyh000留言2022年9月18日 (日) 15:39 (UTC)
有没有半年前或更早的数据?如果有的话,那就能证明A1Cafel真的有如此神功。Sanmosa Királyunk s a közhazát 2022年9月19日 (一) 13:03 (UTC)
之前就此不太活跃。2020年5月~8月等,特色、优良评选,有几次投几十票支持,但具体用了多少时间看,可能无法证明。--YFdyh000留言2022年9月19日 (一) 15:10 (UTC)
赞成单一编辑也无问题,即便容易碰到编辑冲突等问题。从当时的编辑记录来说,全看完再提交编辑存在可能(看完一整日的评选并一次性提交),但细节来说确实令人生疑,不太合理,不太合适。那个时段他首次编辑是11:02在林丽婵条目,03分1票优良条目评选yes,04分1票DYK支持,05分6票、06分3票、07分8票、08分7票、09分13票,都是无意见的支持。如果编辑条目后再看的评选,恐怕是一目十行。审阅完成时编辑无关条目,再提交意见,不无可能但无缘由。打开若干页面审阅、记录意见,再统一提交,以及提交每日(组)花费1分钟,缺乏理由。投无意见支持票的问题,算是普遍且难解的现象。--YFdyh000留言2022年9月15日 (四) 14:49 (UTC)
(!)意见,有一种情况倒是可以明显揪出来:见Talk:全国土地日,里面投支持票的明显连历史也没有看(别说这还可以假定有看,有看的话无可能连条目不够长也不知道;也别告诉我评选不用看历史,基本推荐资格部分规则与条目历史有关,所以投票人有责任看历史),也许可以从这方面入手——诸如当被宣告取消资格时,投了支持票的人会被视为乱投票,当乱投票达到若干次后须在某一期限内被暂停投票权。--街燈電箱150號 开箱维修 抄表 检验证明 2022年9月25日 (日) 10:25 (UTC)
全国土地日那种的叫做例外吧,呵呵。以为这讨论准备结束想关闭的说(反正大量投支持票根本没毛病),结果来一个很讽刺的举例。要不是有几个赶快反映不合要求,是不是这种短条目也要过了?这种“条目候选”的质量评选其实早已苟同了,不用期待那么多。会灌票到底是好事还是坏事?反正一定也有人会想说要是独裁社群不这么做,以后也都不用参选这个“条目候选”了,这玩意会不会过完全是看心情,因为也有那种明显符合标准却没有通过的。痛恨某用户的作品就尽可能不要给票就好了,那么那个用户再怎么写都没用,因为没人支持。原来“条目候选”是这样子的。--Z7504非常建议必要时多关注评选留言2022年9月25日 (日) 10:52 (UTC)
  • 那么,可以规定“胡乱投票”可以放上WP:3RR,然后罚停权一段时间,期间只可以给条目提意见,再观后效。--Temp3600留言2022年9月25日 (日) 17:55 (UTC)
    • 显然都只有美意到而已,成效却是打问号。请问所谓“符合条目候选标准”的定义是什么?看过上面白鲟的例子了没?“新”这个字请问到底有没有想要移除啊?要不然大量投下了符合标准的条目并给支持票也是没问题的啊,不过上面这一个突然冒出来的“全国土地日”例子确实可以有被惊吓到。讲白了,就是最终到底要定义为“疑似拉票”或者“合理灌票”只能选边站,不然以后条目候选真的直接废除吧,完全没意思嘛。况且以后新的条目想要再写出来,难度只会越来越高而已,因为多数都已经被前人写过了,后面的机会只会越来越少。后面的用户真的都只能写诸如时事类条目,比如天灾事件、xxx之死来填补数量。--Z7504非常建议必要时多关注评选留言2022年9月25日 (日) 19:08 (UTC)
  • Z7504其实多人投票参与讨论本质是好事,但居然又要在这里讨论一番是否不恰当, 囧rz……(顺带一提,感觉特色列表评选也好像没什么人参与评选和讨论)。ThirdThink留言2022年10月5日 (三) 10:14 (UTC)

提议DYK允许使用陈述句。

理由如下:

  1. 一些编者为了让答案唯一而硬凑问题,叠加多个条件,导致问题变得非常冗长。
  2. 一些问题根本没有吸引力,无法吸引读者点击,不如直接把答案展示出来。
  3. 一些事实本身已经足够特殊,但是因为答案不唯一而不得不继续叠加一些其它条件,或者使用“除了……之外还有”的方式排除其它答案,这些都降低了可读性,不如改为陈述句,使用“最……之一”的用词。

举例:

  1. Talk:开基天后宫,原问题为“台湾府城唯二建于明郑时期的妈祖庙除了大天后宫外还有哪一座妈祖庙?”我认为完全可以改为“开基天后宫修建于明郑时期,是台湾最早的妈祖庙之一”。
  2. Talk:镭,问题为“除了以外,居里夫妇还发现了哪种化学元素?”存在更有吸引力但是答案不唯一的事实,例如“元素具有强烈的放射性,但是却曾被用作发光颜料。”
  3. Talk:梼杌剑虎属,为了保证答案唯一而叠条件“并且是“半剑齿虎属勇剑虎属锯齿虎属”演化过程中产生的一个旁支”,导致问题过于专业化,欠缺对读者的吸引力,如果允许使用陈述句,就完全可以改成“2021年新发现的剑齿虎梼杌剑虎属的名字来源于中国古代传说中的凶兽。”
  4. Talk:中华人民共和国机动车行驶证,完全可以改为“机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证”。

--——🦝英特浣熊耐尔留言贡献 2022年11月2日 (三) 10:06 (UTC)

(+)支持,每次都是绞尽脑汁想问题,好像在问题上花的时间比条目本身都要多了。-- B-MIKE -| 2022年11月2日 (三) 17:20 (UTC)

特别提示:过去曾经有过如下讨论:“提议调整新条目推荐问题指南时效性描述(暂时性折中方案)”,该讨论围绕DYK的时效性进行,并在中途有至少AT明确表示要求改革,而Temp3600等人也没有对其表示反对。魔琴表示过“不是很支持废除提问”但也不知道理由。我个人希望这次讨论不要再绕回“时效性”的老问题上画圈。 --MilkyDefer 2022年11月2日 (三) 14:01 (UTC)

(+)支持,DYK问题过于苛刻,有些真的很丢吸引力。还有,什么都要加个“截止到某年某月”,很无聊,不写的话不就默认截止到现在吗?“中国历史上唯一的女皇帝是谁?”这个问题,在705年发表和在2022年发表又有什么区别? ——魔琴 留言 贡献 ] 2022年11月2日 (三) 12:33 (UTC)
您没有考虑万一将来中国大陆重新称帝的情况啊,怎能这样写啊。啊,怎能写到某年某月呢,万一明天就过期了得怎办呢。--Ghren🐦🕘 2022年11月2日 (三) 13:32 (UTC)
当你在按月份查看过去的新条目候选存档的时候你就应当已经知道这个DYK项目的有效时间点了。 --MilkyDefer 2022年11月2日 (三) 13:42 (UTC)
过往发生过有问题在首页展示途中还未下架就发生“现在”已经失效的情况,所以才有这个要求。另外注意主题首页的DYK存档是不记时间的。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月2日 (三) 14:07 (UTC)
有按日存档的(Wikipedia:新条目推荐/供稿/2022年11月1日),只是Wikipedia:新条目推荐没有这样按日列举,可以参考英维的对应页面那样按天划分。如果是担心问题还未下架就失效,那能确保在短期(甚至只需要一天内)有效就行,何必需要永久呢。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 15:03 (UTC)
我想上次已经有说过,我们不能确定一个条目在哪一天登上首页和Portal,以及一个条目会展示多久时间(Portal那边试过有DYK条目放在首页三年),所以确保在短期有效的可操作性不高。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月2日 (三) 15:10 (UTC)
算了这个时效性可以以后再谈,反正多几个字观感不会很差,重点是解决陈述句的问题。 ——魔琴 留言 贡献 ] 2022年11月2日 (三) 16:12 (UTC)
(+)支持,一个条目或多或少会有一两个所谓可以放上来的“冷知识”,但未必能问出问题来。 --MilkyDefer 2022年11月2日 (三) 13:42 (UTC)
我认为时效性还是要考虑的,不过就简单加一个限制条件。至于废除强制提问格式,倒是没什么意见,不过还是建议能提问就提问吧。—— Eric Liu 創造は生命(留言留名学生会 2022年11月2日 (三) 14:14 (UTC)
(+)支持废除强制提问格式,我也常常不得不为一篇想不出有什么特别的条目硬生生地提出个根本没有吸引力问题,确实很没意义。不过需要(※)注意陈述句和疑问句并行可能导致读者观感不佳。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 14:37 (UTC)
我未见这些陈述句比原问句更有吸引力和趣味性,甚至可以说吸引力和趣味性几乎是不存在的。Fire Ice 2022年11月2日 (三) 16:45 (UTC)
  • (+)支持,终于有不少用户觉得DYK一定要使用问句提问是很麻烦的了吗?看谁以后还要提议把“新条目候选”更名为“条目候选”吧。这种早期中文维基百科的DYK制度真的该改改了,要不然以后还是都只能“截至某个时段为止”、“是哪个”等问句的问法。不过,也不应该说以后问句的问法就要废除,这类陈述句的题目还是要有一定逻辑才行。还有,请问DYK题目的答案还要保持唯一性吗?如果是,那就实质上来说还是没有改革,到头来就是美意打折扣而已。为何要确保DYK题目的答案唯一性呢?有不少名称都有多种说法,凭什么只能是其中一种说法当DYK题目的答案呢?也已经强调到烂掉不想说了,以后还想写出“条目候选”的难度只会越来越难。因为条目都被前面的人写去了,请问后面的人是要写什么?几乎没有东西了啊。这个独裁社群倘若再不认真思考改革“条目候选”,也没什么人愿意要写维基百科了。因为若基本想要查询的信息都可以在维基百科查得到,那样哪还有写“条目候选”的必要呢?更别提有时还因为没有足够支持票而落选DYK的不占少数,呵呵。要不要鼓励人拉票呢?独裁社群仔细想过吧,“新”一字真的该废除了。--Z7504非常建议必要时多关注评选留言2022年11月2日 (三) 17:35 (UTC)
  • (~)补充:讲一个“条目候选”很明显的例子:

答案:“管理方格理论”。那到底是为什么就不能开放其它也是正确的答案(管理格道、五分式领导)当作“条目候选”的答案呢?难道还要执著“DYK题目的答案唯一性”吗?--Z7504非常建议必要时多关注评选留言2022年11月2日 (三) 17:40 (UTC)

为何不能问:管理方格理论是谁建立的?--百無一用是書生 () 2022年11月3日 (四) 02:47 (UTC)
也就是说,不将新条目推荐问题之主体限定在条目本身,而是条目之内容亦可,对吧?我同上面几位持类似看法,觉得这是一个不错的形式。—— Eric Liu 創造は生命(留言留名学生会 2022年11月3日 (四) 03:58 (UTC)
确实可以这样问,但此时问题可能就要变成整条都要蓝连了。即:“管理方格理论是谁建立的?”--Z7504非常建议必要时多关注评选留言2022年11月3日 (四) 05:12 (UTC)
不隐藏条目名就只链条目名,才对吧。--YFdyh000留言2022年11月3日 (四) 05:27 (UTC)
管理方格理论是“由罗伯特·R·布莱克简·莫顿于1964年共同建立的领导风格模型理论”,如果要用同样这个问题套用在这两位上,请问该用罗伯特·R·布莱克还是简·莫顿做答案才对?还是两个同时上去?虽然知道这两位不大可能被提名“条目候选”,但这样显然就已经不符合首先提过的“DYK题目的答案唯一性”了。--Z7504非常建议必要时多关注评选留言2022年11月3日 (四) 05:35 (UTC)
没有强制用陈述句,只需“与某某一起创建了……”(嫌短可改成“哪位xx学家)。同时登上,顶多是谜底在谜面上,而且设定type参数似乎能避免此情况?--YFdyh000留言2022年11月3日 (四) 06:00 (UTC)

(!)意见:如果允许不隐藏条目名称的问句,那么将有可能出现同一条问句但可以被两个条目使用的情况,例如:

  • 化学元素是哪位物理学家与他的妻子一起发现的?
  • 化学元素镭是哪位物理学家与他的妻子一起发现的?

如果两个条目同一时间参加评选,不怕在评选时会混淆投票者吗?(例如投票者本来想投给,但因为看错了相同的问句而投错给皮埃尔·居里)另外反对取消时效性,除非首页随时失效的问题有完美解决方案。--Maccomcre留言2022年11月3日 (四) 05:04 (UTC)

您漏掉了,如果他的妻子也有知名度,也是可以参选的。如果要反对时效性用法,真的就是所谓的没有改革结案而已,一点意思也没有。总之,“条目候选”的问题本身就一大堆。“罗马不是一天造成的”,如果想要认真改革“条目候选”那就仔细想清楚吧,否则以后这页面就是逐渐往淘汰的方向了。--Z7504非常建议必要时多关注评选留言2022年11月3日 (四) 05:12 (UTC)
不感觉会那么巧合。完全可以微调语句。可以指引级劝止同期采用相似句子。投票者看错是投票者责任,有加粗和条目名信息。--YFdyh000留言2022年11月3日 (四) 05:29 (UTC)
投票看条目名应该是看那行小字吧( ——魔琴 留言 贡献 ] 2022年11月3日 (四) 07:57 (UTC)
如果DYKC的投票者们真的都是认真投的,我就不会问这个问题。但现实是DYKC很多人都是粗心随意,说他们有责任感、会看小字而不会搞混,完全是痴人说梦话。--Maccomcre留言2022年11月3日 (四) 08:35 (UTC)
不管是否同时、问题是否相似,看错/评错条目都可能发生。除非强制填写有意义的理由,但那是另一个议题。--YFdyh000留言2022年11月3日 (四) 09:36 (UTC)
其它情况也会有这种混淆我当然知道,只是想说两个相同问句以现在社群心态来看,混淆的机会应该会比较高。--Maccomcre留言2022年11月3日 (四) 10:21 (UTC)
  • (+)支持,直接把首段定义句抽出来,方便又快捷,不用花费无谓的时间去想问题。—AT 2022年11月3日 (四) 09:44 (UTC)
  • 初步衡量了上面的意见,敝人也不得不承认完全改为陈述句、完全废除问句最好,那么就完全不用争论问句会产生什么问题。但陈述句还是有需要设置时效性,像是上面行驶证的例子至少也要改为“自(某个时间)起,机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证”;单单“机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证”的话,如果上首页当日大陆政府突然推出新政策要带另一种证还要即时生效,那就完了。首页始终是可见度极高的地方,一些极端罕见的情况我们也不应该忽视。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月3日 (四) 10:11 (UTC)
    如此约束时效性我认为将过于复杂、舍本逐末,很多东西不可能用一句话准确概述,比如试点地区、政策曾经暂停、条件性许可等情况。“要带另一种证还要即时生效”可能不该过分担心、是设问句有问题,至少还有驾驶证,抬杠还有年检标(也已试点电子版)等。--YFdyh000留言2022年11月3日 (四) 10:35 (UTC)
目前不赞成完全改成陈述句,风格变化过大,可能会有实际问题(比如地区词和别名处理?)。--YFdyh000留言2022年11月3日 (四) 10:26 (UTC)
大概允许陈述句和疑问句并存会是这样的效果,不知社群怎么看。--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 12:36 (UTC)
以上感觉很怪,但应该是文法问题,完全没有给出有吸引力的元素。以下如何:
--YFdyh000留言2022年11月3日 (四) 13:18 (UTC)
  • 应该就只有中文版会以疑问句为DYK条目作引吧,其他版本的做法一般是把介绍条目的短句套在“你知道⋯⋯吗?”这问题里头,或者像日文版那样,直接写一段小作文介绍条目。我对是否解套陈述句没什么意见,但感觉这个问题与其说是有没有人支持的问题,倒不如说是执行上的问题:首先,总不能“(你知道)哪个铁路站位于香港体育馆和红磡海底隧道的旁边(吗)?”和“(你知道)机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证(吗)?”一起出现在DYK模板里吧?撇除有趣没趣这一点,这样做对后者可能有点不公平(谜底都揭开了,读者还会想去读吗?)。其次,你们如果要废除问句,那可能就得画一条界线,截止日之前提名的条目仍然要遵守既有的问题规范,之后提名的条目就适用新的介绍规范(?)。另外也要保证最后一条使用疑问句作引的条目不会上画2小时后就被刷下来。至于时效性问题,我有想过能不能在DYK模板加一条备注去回避这个问题(像“上述事实以条目当选时为准,详情请参阅条目讨论页”这样)。--春卷柯南-发前人所未知 ( ) 2022年11月4日 (五) 02:51 (UTC)
    (你知道)机动车驾驶人在中国内地驾车上路时要不要随身携带机动车行驶证(吗)?--百無一用是書生 () 2022年11月4日 (五) 03:24 (UTC)
    “谜底都揭开了,读者还会想去读吗?”怎么就知道读者不会去读呢?有没有什么数据或理论支持这种假说?--百無一用是書生 () 2022年11月4日 (五) 03:28 (UTC)
    英维基本绝大多数都是陈述句。我认为“元素具有强烈的放射性,但是却曾被用作发光颜料。”绝对比“除了以外,居里夫妇还发现了哪种化学元素?”更优吸引力。--——🦝英特浣熊耐尔留言贡献 2022年11月4日 (五) 09:01 (UTC)
    此句中“镭元素”改成“什么元素”,我觉得更有吸引力,但实践中可能有答案唯一等问题。不然它只是一句小知识,不太让我产生了解镭元素的动力。--YFdyh000留言2022年11月4日 (五) 09:04 (UTC)
    答案确实不唯一。--——🦝英特浣熊耐尔留言贡献 2022年11月4日 (五) 13:25 (UTC)
    我想书生兄是看不到他想要的硬数据,但我想表达的意思是,单纯的疑问句会显得比单纯的陈述句有趣,语文课本该有说过使用疑问句作引,可以利用读者的好奇心,吸引他们的注意吧。不过,如果加入“是否有趣”这个变量,我这个立论可能就要打个折扣,好比我就说不出“(你知道)哪个政党曾在2014年推出充斥着女子叫床声的竞选广告(吗)?”和“(你知道)《月亮代表我的心》是马来西亚伊斯兰党的竞选歌曲(吗)?”哪个会比较有趣。-春卷柯南-发前人所未知 ( ) 2022年11月4日 (五) 18:13 (UTC)
    就“谜底都揭开了,读者还会想去读吗”,有谜底我也未必想阅读,要看这个主题和可能涵盖的内容是否有意思。如果很容易猜到谜底,或者看了标题就大概知道写了什么,我可能同样不想阅读。--YFdyh000留言2022年11月4日 (五) 04:27 (UTC)

(?)异议:如果二者并存,设想疑问句在上,陈述句在下,毫无关联的两个事物相邻可能会令读者误解,比如:

  • 《港区国安法》首案被告是谁?
  • 香港女子某某某由于在法庭对被告致辞鼓掌和召唤包青天,被判煽动罪成立。

如何解决此问题?——Gohan 2022年11月4日 (五) 14:00 (UTC)

这种情况不好解决,也许只能依靠使用相同的type参数来避免同时展示?即便只有设问句,也可能有此种巧合与误解发生吧,所以我觉得无须过度担忧。--YFdyh000留言2022年11月4日 (五) 18:40 (UTC)
上条日本地理,下条台湾建筑,并不少见。相同type意味着不同的轮候机制。--Gohan 2022年11月5日 (六) 01:53 (UTC)
个人认为不是什么大问题,非要解决的话可以把现在每项前面加上序号。--Kedouv留言2022年11月5日 (六) 05:56 (UTC)
@神秘悟饭:我自己反而感觉疑问句与陈述句同时出现不会有太大的问题。就你举的这个例子而言,正常人的阅读是一定会看上文下理的,但凡看一看格式就知道这相邻的两项原则上并无关联。Sanmosa Je sers 2022年11月24日 (四) 15:05 (UTC)

(+)滋磁,双手赞成。只要能顺接“你知道吗”,根本没有必要限定句式。当然以后评选时可以就标题的趣味性本身多做讨论,鼓励大众更积极的对评选中的DYK标题提供建设性意见。--南冥大鹏👈批判我一番报道有偏差Ω微小的工作历史的进程 2022年11月4日 (五) 23:52 (UTC)

关于是否会引入其他问题

  • 我们站内的大河内教授一言:“提案是否会引入其它问题?如果会,该问题是否重要?如重要,有何措施加以弥补?”

诚然推行允许陈述句格式能解决很多问题,然而也会出现新的问题;比如上面有编者就提到统一格式的混乱疑虑,这就进而衍生出了现行提问方法需不需同新法并行?如果有格式混乱,现行提问是否需废除?我想截至目前各位的主流意见都是认为陈述句可被允许,但也请探讨之后的问题。如果后两个问题没能得解决,我认为乃非各位一句“直接陈述好”“强制提问坏”的局限性表态能够解决的。——咏梅阁—WMLO留言2022年11月7日 (一) 23:44 (UTC)

对于格式混乱的问题,我认为可以通过轮流展示的方法来解决。比如已通过的提问形式DYK达到6篇的时候便可一同登上首页,陈述形式也是一样,这样就没有格式混乱的问题。--AT 2022年11月9日 (三) 02:38 (UTC)
由于不希望条目展示的时间少过半天,这样做的话机械得最少隔半天才能更新一次,意味着机械将会很难自动调节频率(不能逐条计算时间)。而一旦需要更新的其中一边的下一个轮次花费了较长时间才等满6个时,整个更新程序会出现拖延问题。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月9日 (三) 03:03 (UTC)
虽然我说了轮流,但是如果其中一边较多的话,而另一边不足6篇的时候,那可以让更多的一边先上首页,这样的话应该就没有拖延的问题。--AT 2022年11月9日 (三) 04:06 (UTC)
这顶多只能解一半问题吧,两边都不够数的话就只能让人干等了。就以上个月的排队情况来看,同时至少10篇已确认数量的时数占不到一半,假如上个月就已经这种方法来更新(也假设陈述句和问句使用情况是一比一),估计会令不少条目在投票完后还要等多约两天才上到首页。简单说就是现有的方法评选越冷清就等得越短时间(完了几乎即上);而您提到的新方法就有点反了过来——评选冷清时等候的时间可能变长(完了再要等齐人)。如果因为条目太多而要久等这下还算正常,但条目太少也要久等的话这下就不十分好了。而且这种方法会否让提名人产生跟大队的心理?——明明想用陈述,但当下看见没几多人用陈述,为了避免花时间等齐人而放弃使用陈述。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月9日 (三) 05:37 (UTC)
这样的话也许可以考虑同时采用定时制,比如说通过后一天内,如果任何一边达6篇的话先上,两边都不足6篇的话,先让近期未上的一边先上。然后,再设下限,例如当已经通过超过两天的DYK优先上首页。具体来说,比如1月1号有12篇陈述,3篇提问通过,根据这个建议,先让陈述的6篇先上首页。之后一天内如果提问累积达6篇,便让其先上首页,再到陈述,如果提问仍然不足6篇的话,让陈述剩余的6篇先上。去到1月3日,无论陈述有多少篇均让提问先上。当然这个时限是可以讨论的,甚至上首页的数目也可以商讨,不一定是一天两天或6篇。至于跟大队的问题,我觉得DYK没什么好急,反正通过的话迟早都能驞,快点上也没什么特别的好处,因此诱因不大。况且,如果出现一边倒的情况,导致有人愿意妥协的话,我想那就是时候讨论弃用没人用的一边了。--AT 2022年11月9日 (三) 07:06 (UTC)
只能说机器的改造工程会很浩大吧,中间要计算的东西多了几重,不太有信心可以很快改得好…… --街燈電箱150號 开箱维修 抄表 检验证明 2022年11月9日 (三) 07:40 (UTC)
要兼顾多方面下的必然结果...或者看看有没有人有更好的方法吧。--AT 2022年11月9日 (三) 11:41 (UTC)
我觉得AT这个方案停怪()如果每个句子前面加上一个小图标会不会解决?
以上举几例试验一下。 ——魔琴 留言 贡献 ] 2022年11月10日 (四) 17:58 (UTC)
感觉有点乱,可能喧宾夺主。问号和叹号的区别不太明显。新增句式可能不错。不太赞成条目链接放在长句尾部,粗体不是很明显。如果多个内链,被内链的其他条目应同时保证足够的质量。--YFdyh000留言2022年11月10日 (四) 18:05 (UTC)

  • 香港女子某某某由于在法庭对被告致辞鼓掌和召唤包青天,被判煽动罪成立。

  • 机动车驾驶人在中国内地驾车上路时需要随身携带机动车行驶证吗?


那我觉得这样更好。—AT 2022年11月11日 (五) 04:42 (UTC)
占用空间变大了不少。长句如果折行(宽度受限)还好,不然排版可能不好看。--YFdyh000留言2022年11月11日 (五) 13:07 (UTC)
  1. 《港区国安法》首案被告是谁?
  2. 香港女子某某某由于在法庭对被告致辞鼓掌和召唤包青天,被判煽动罪成立。
  3. 机动车驾驶人在中国内地驾车上路时需要随身携带机动车行驶证吗?
  4. 开普勒定律是谁发现的?
  5. 开普勒定律是谁发现的
有序列表呢?--Kedouv留言2022年11月11日 (五) 06:19 (UTC)
本就不分先后、可能随机展示,所以不太建议有序列表,以免过度解读排名。--YFdyh000留言2022年11月11日 (五) 13:07 (UTC)
上面的示例中的两个“开普勒定律是谁发现的?”就看起来很容易混淆。--BlackShadowG Slava Ukraini! 2022年11月20日 (日) 14:10 (UTC)
举了一个比较极端的例子,才能看得出问题 囧rz……所以该怎么解决,三个方案似乎都不是合适。 ——魔琴 留言 贡献 ] 2022年11月22日 (二) 17:37 (UTC)
@AT@BlackShadowG@Cdip150@Kedouv@YFdyh000@魔琴 如果最终在这里没能讨论出统一的抉择方式,不妨使用公投解决如何?——咏梅阁—WMLO留言2022年11月23日 (三) 21:36 (UTC)
如果全部方案都有缺点,且各自的缺点都足以导致不能使用,投票强行得出方案只是徒然,因为都执行不了。而且综观以上各人的意见,敝人也认为全部方案都不行。况且,社群对于能不能同时混合两种展示?就以上的意见来看也没有明显的共识,连这个共识都没有的时候,直接票选方案也没有意义。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月24日 (四) 04:36 (UTC)
那建议不妨先针对混合展示与否此议题提出公决,比如:“针对DYK之推广,您认为社群应从以下方案中选择哪项以应对现有之观感?
  • 应维持现状继续使用提问式;
  • 应废除提问式仿英维等使用陈述式;
  • 应发展中维特色DYK推广主义,允许两类并行。
若前二项之一得到通过,那方案使用的问题也得到解决,因为这只是换道菜与否的问题。如果是第三项得到通过,可能比较麻烦,但届时也应有适当的环境针对此问题如何解决的讨论,就如同这一年来针对RFA选举的讨论一样。简单来说,应先解决最基本的问题,否则这类讨论最终显也只会无共识结案。——咏梅阁—WMLO留言2022年11月24日 (四) 13:29 (UTC)
先前讨论有点杂。我觉得暂时“试行”允许陈述句(不强制要求问句)就好,如果“问题不当”,全可“用脚投票”,以便看出哪种更受欢迎、实际场景出现的问题。具体的展示和表述方式,似乎暂无共识,但可见当前方式存在多个反对,也非共识。--YFdyh000留言2022年11月24日 (四) 13:39 (UTC)
不过有别于RFA、GA评审制这两个仅关联社群内部的试行方式;这次试行将直接牵涉到读者面对首页DYK的观感...关于这点,各位觉得没问题吗?——咏梅阁—WMLO留言2022年11月24日 (四) 13:45 (UTC)
我自己是觉得允许两类并行也没大问题,毕竟也算Unity in diversitySanmosa Je sers 2022年11月24日 (四) 15:08 (UTC)
目前应该尽早接纳使用陈述形式,再来考虑如何并行或是否废除提问形式。至于提问和陈述相冲的问题,基于type能够挡掉大部分同类条目,我想问题不大。--AT 2022年11月24日 (四) 15:56 (UTC)
目前上方疑虑意见在于:1. 问题与陈述相连会误以为是设问;2. 同问句不同条目会导致混乱;3. 其它关于新句型的观感问题。我觉得1、2出现概率极小,而且正如AT君所说,type可以挡掉同类条目(即疑虑1“设问”,对应上方举例的1“国安法首案被告”和2“香港某女子”)。故我支持按现行格式试行接纳其它句式(陈述、不藏条目的问句)。 ——魔琴 留言 贡献 ] 2022年11月24日 (四) 18:19 (UTC)
“同问句不同条目”若非刻意安排应较难出现,又或者等到两个条目的提名皆通过,再合并成一句多个粗体条目上首页?例如“开普勒定律哪位天文学家发现的?”或者是en:Wikipedia:Did you know/Multiple Article Hook Hall of Fame的极端例子。假如仅有部分提名通过就只为通过的条目加粗。——留言2022年11月24日 (四) 20:33 (UTC)

(-)反对试行,因为都已经看到效果是怎样:

认同上面有人说两种并行观感不佳,结尾有时问号有时又句号,我也觉得是一团乱,完全感受不到趣味在哪里。--Maccomcre留言2022年11月25日 (五) 05:43 (UTC)

其实日常生活中似乎都是陈述性质的疑问句,就如以下几例:

例一

- 这座塔真高啊!- 是啊,你知道这座塔有338米高吗?

例二

你知道人要呼吸吗……如果知道的话你就不会那么惊讶了。

例二

你知道如果总是用你知道吗句式来说话会被附近听你说你知道吗的人感到不舒服吗?

——诚挚的 ZhaoFJx 2022年12月6日 (二) 14:00 (UTC)

先从三个选项之中取一个基本的共识

@AT@BlackShadowG@Cdip150@HTinC23@Kedouv@Maccomcre@Sanmosa@YFdyh000:还是主张因先将此议题之基要(即维持现状、废提取陈或两类并行)付诸安全投票。应先取主流意见,再据此想办法解决。有一个基本的共识,才能有合适讨论的基础。否则就如街灯同志所言,连并行与否的共识目前都不知道,自然讨论是无法持续下去的。诚然,投票是解决问题的最终手段,可终究不想让此讨论无疾而终。——咏梅阁—WMLO留言2022年11月25日 (五) 12:30 (UTC)
个人是支持两类并行的,但同时认为其他维基人提出的混合展示导致的混乱也有解决的必要,以上的讨论也是主要围绕这一问题展开的。暂且再提一方案:陈述与提问分别展示,推送新项时判断是哪一种类型,如新项为陈述句则展示陈述列表,反之亦然;特别的,开始时因陈述句不足六句则不展示,待数量达到时开始展示;此法唯须应对陈述最早的5项展示时间少于其余项(且越早时长越短),不过或许应该大概有人愿意。--Kedouv留言2022年11月25日 (五) 14:11 (UTC)
或许会比AT的抱团方案清晰一些。 ——魔琴 留言 贡献 新手2023计划 ] 2022年11月25日 (五) 19:16 (UTC)
这样做的话条目会出现当选条目上了不久又下下了不久又上(6次)的情况,敝人并不赞成这种展示方式。一来在确保每个条目展示至少12小时的技术难度比AT的方案还要大很多(AT的方案难度本来就已经不小),二来是这样的上上落落可能会让读者疑惑:条目暂时下架的期间是否出现了什么问题。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月26日 (六) 04:46 (UTC)
按目前的更新频率即可保证每条最少12小时的展示时间(即6个更新等候时长),只是展示时间段变得碎片化,除了陈述句最开始的5条;另外读者大概不会一日内每隔一小段时间就访问一次首页并去看DYK,发现上上下下的可能性并不高。不过用AT案我也不反对。--Kedouv留言2022年11月26日 (六) 11:07 (UTC)
每天一早一晚各看一次的读者应该不少,而近期的更新频率以每4至6小时为主,现行方法依照这个频率会使一个条目由开始上架到真正下架需时24至36小时,而您的方案需时应该是现有的两倍,即48至72小时,横跨了两三天。当有人第一天早上7时看到条目A,晚上10时条目A不在,第二天早上7时条目A又再出现……这样让人看到上上落落的可能性其实一点也不低。--街燈電箱150號 开箱维修 抄表 检验证明 2022年11月29日 (二) 09:44 (UTC)
反过来看,此讨论的参与者似乎大多均支持使用陈述,而且大多反对使用提问或认为可以并行,似乎也未见有人坚持只采用提问形式。这样的话,是否应该考虑先改成陈述,再看看提问形式应该废除还是通过什么技术手段达至并行?这样更贴近目前讨论的方向。--AT 2022年11月26日 (六) 13:26 (UTC)
个人感觉调整的话需要面临的问题很多,目前反对调整。--Fox6667留言2022年12月3日 (六) 17:59 (UTC)
鉴于首页的重要性反对直接引入陈述句。个人仍建议先试行废除强制“what”“which”发问的规则,并鼓励DYKC的参与者对削足适履前述规则的问题提出替换意见。既然DYK本身就有舶来色彩,再度参考英维现状进行改进也是应有之义。引入陈述句应视为疑问句放宽到极限后仍不能解决问题才考虑的手段。——DvXg 📬 2022年12月6日 (二) 09:15 (UTC)

中维的FA、GA、DYK等评选是否可以改为英维的审议制而非强制投票制?

目前许多地方的投票制已经引发社群多次质疑和讨论,动辄被认为有灌票嫌疑(甚至有不拉票即不能通过的说法),而且许多评选参与者不多,几乎将沦为虚设,强制性的票数界限反而使许多达标页面仅因为评选无人光顾而未能获选,关于改为英维审议制,社群又何看法?欢迎大家讨论。--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年9月26日 (一) 04:47 (UTC)

如果审议人审议通过了不合格的条目,该负什么样的责任?审议人审议条目,又能获得何种激励?好奇这个审议制度如何运行。Fire Ice 2022年9月26日 (一) 08:11 (UTC)
我也不了悉英维为何能这样运作而不至于出问题,亦不清楚中维是否这样运作会出问题--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年9月26日 (一) 10:31 (UTC)
英维似乎FA、GA、DYK都没有激励机制。看过一些GA就一个人审议,标准弹性很大。也存在公开交换审议的情况。--Benevolen留言2022年9月26日 (一) 10:53 (UTC)
如果审议人审议通过了不合格的条目,该负什么样的责任?审议人审议条目,又能获得何种激励? - 个人觉得这些问题不存在,而实话实说和这种话很像:如果IP用户写出了不合格的内容,该负怎么样的责任?IP用户编辑条目,又能获得何种激励?
关于不合格条目,可以读读英维重选流程。两种方式,并且可以以个人的方式进行重选。--0xDeadbeef留言2022年9月26日 (一) 13:12 (UTC)
你应该和如下例子类比:如果巡查员巡查通过了不合格的内容,该负怎么样的责任?巡查员巡查条目,又能获得何种激励?当然,DYK、GA、FA比新条目巡查责任更为重大,他们将被推上首页,甚至读者要是点击图标,还能看到“优良条目是我们认为质量令人满意,但未达典范标准的条目”等内容,甚至是“我们认为这些条目详尽而深入,符合特定要求,是维基百科条目之杰出典范。”如果审议人把诸如远东华人强制流配的原版这类东西选为FA,将来媒体报道顺便提到某维基人“有三篇条目被评为优良条目,一篇被列为典范条目——此条目还被其他语言的维基百科用户翻译为英语、俄语、乌克兰语、罗马尼亚语以及阿拉伯语。”谁来负这个责任,该负什么样的责任?Fire Ice 2022年9月26日 (一) 13:56 (UTC)
GA、FA推上首页难道不是需要更多人审议吗?英维的DYK在上首页之前都需要管理员进行批准的。至于FA在英维上可也是需要多个人审核达成共识。所以GA真的责任重大,必须投票表决吗?如有问题则处理问题,无法处理问题则是另一个问题。如有GA捣乱的,轻者WP:TBAN,重者直接封禁不就行?--0xDeadbeef留言2022年9月26日 (一) 14:06 (UTC)
当下GFA就是无人负责的,如果审议制度同样无人负责,和当下制度又有什么区别呢?Fire Ice 2022年9月26日 (一) 14:09 (UTC)
维基百科不保证其内容正确无误”,本来就不负责。只是换一个更高效的制度是可以考虑的,不过正如下面提到的同行审查也未必“高效”,甚至可能更糟糕。
目前限期评选还能变现推进审议流程,如果同行审查,条目若没人有兴趣的题材,挂几年也是很正常的,又变成另一种积压工作。--Nostalgiacn留言2022年9月29日 (四) 08:12 (UTC)
如果是按标准打勾勾的话,只不过变成自动灌票罢了(一次提交,一次“自动”判断标准,一次同意通过)。如果是人审议的话,出现标准意见冲突怎么办?甚至说现在投票机制,有点像按标准进行人工审议罢了。——Sakamotosan路过围观 | 避免做作,免敬 2022年9月26日 (一) 09:01 (UTC)
我们至少需要具备基本的编辑经验/能力的用户才可能做好这一点吧?--百無一用是書生 () 2022年9月26日 (一) 11:44 (UTC)
机制亦需要充分考虑到不同专业、个案和特型等方面,若果依据本地实际,认为仅能由特定试验之专案做略为检视操作,在全方面而言相关条件之现实门槛还需更多补足。--约克客留言2022年9月26日 (一) 12:44 (UTC)
英维这套方法不适用中维啦。--~~Sid~~ 2022年9月26日 (一) 13:18 (UTC)
(?)疑问:万一缺乏合适的人选怎么办?就好比折毛之前写的若干篇FA、GA或者DYK有很长时间都没有人发现造假,请问这到底是为什么呢?所以目前还是先把人手不足这件事情解决了再说吧,人家英维的审议制也是典型因地制宜啦,中维不应该也是嘛。--绍💓煦集思广益 2022年9月26日 (一) 22:41 (UTC)
  • 懒得再讲什么了,如果这种东西就是一种无法解决的Bug,那通通都是多讲的,一点意思也没有。“非强制投票制”这玩意,记得和以前共识制讨论非常像。其实就是喊喊口号而已,但这种东西啊完全实施不起来。如果没有办法实施的,真的都是多讲的,没有讨论必要性。--Z7504非常建议必要时多关注评选留言2022年9月27日 (二) 07:05 (UTC)
  • (▲)同上 仅是小范围中时而可行的乌托邦,很容易跑偏无共识。如果是想促成深入的同行评审,弄成可选机制、增加权重就好,流程参考还算能运转的DYK规则、PJ:AFC、典范/优良评选、WP:RSN等。--YFdyh000留言2022年9月27日 (二) 07:45 (UTC)
折毛事件的时候也有过类似的讨论,还是那个观点“这个系统更像是各专题评级的升级版,各专题有一定数量的评选人员,才能比较好地进行实施这个系统。另外,基于不同评选人员的标准,质量可能会飘忽不定。”
另外同行审查也不能解决“评选无人光顾而未能获选”的情况,实施这个制度的粤维也有超过两年(甚至三年)都没有人开启审查的情况。而且有些优特审查很水,如这个。--Nostalgiacn留言2022年9月28日 (三) 13:58 (UTC)
粤维人数和中维不可同日而语吧--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年10月2日 (日) 10:01 (UTC)
抽取的时间记录也不一样啊,列举个案是很早期之情形,如点入正版参阅(UTC时间总看得懂吧)可是轮候漫长呢~另外提示一点,粤维上了新一波管理用户、整个体系在部分操作上可能比中维更中维化,所以到底比较起来怎么样都很难说咧--约克客留言2022年10月2日 (日) 12:02 (UTC)
(...) 吐槽我的DYK恐惧症就是这么来的...-- B-MIKE -| 2022年10月31日 (一) 14:09 (UTC)

试行一次

吵这么凶大家都是在纸上谈兵,应该要实际做一次才能知道好不好才对。要不这样,我提议实际使用一个典范条目评选试行一次审议制度。这样有没有问题、会不会有问题就全部显现出来了。参考英维的评选制度,一名协调员拥有是否入选的最终决定权,这也解决了所谓的无人对审议结果负责的问题。

所以我就是说,大家是否愿意让下一篇典范条目评选由我作为协调员实际做给大家看一次是否可行,否则这个讨论永远都是没有任何论据的辩论,不及格。 --MilkyDefer 2022年9月28日 (三) 07:36 (UTC)

谨表( ✓ )同意示之。--约克客留言2022年9月28日 (三) 09:09 (UTC)
( ✓ )同意 --0xDeadbeef留言2022年9月28日 (三) 09:17 (UTC)
(=)中立,反正上面都举例过了,如果说学学Cdip150管理员建设一个过滤器的话,或许可以试试看。但在这就不再瞎扯些什么了,估计又要来一个不知道得讨论多久的讨论串,不要玩到最后又是一个相同模子、不同包装的讨论,那真的一点意思都没有。--Z7504非常建议必要时多关注评选留言2022年9月28日 (三) 16:51 (UTC)
赞成。对于我熟悉的领域,我愿意作为评议人参与。(如果我有时间)--洛普利宁 2022年9月30日 (五) 02:55 (UTC)
支持,如果是我熟悉的领域,我愿意作为评审人参与。--——🦝英特浣熊耐尔 就一定要实现留言贡献 2022年10月2日 (日) 08:47 (UTC)
值得一试。--EzrealChen留言2022年10月2日 (日) 09:05 (UTC)
  • 尽管我不觉得能够阻止什么: RFA试行与条目评审试行其实有很大的分别。RFA总是能够吸引大量用户前来,制度本身无非是怎样令大家服气而已。条目评审的本质问题是对某一方面有专攻的用户不足,因此如果按自己的初步观念投票,就有乱投、灌票之嫌; 如果总是由两三大佬投反对票,又有对新人不公云云。现在试行万众瞩目,将各路精英聚集起来,自然能撑起场面,但日后又怎办呢?--Temp3600留言2022年10月7日 (五) 10:10 (UTC)
    • (:)回应:典范条目几大标准:全面、流畅、专业、考据全面、稳定、遵循格式手册、媒体使用恰当、长度合理,对审查者的能力标准要求是不一致的。审议制度允许审核者只针对这其中的部分标准提出支持,协调员会检查候选条目是否完整地接受了检查。因此,审议制度可以让评审者有力出力,回归典范条目标准,同时阻挡远东华人强制流放这种做了来源检查就能发现问题但是偏偏没人做就已经够票了的条目通过。投票制度在另一方面,投下支持票不需要说明理由,一个“符合典范条目标准”到底是否完整涵盖了所有标准呢?不知道。有责任心的人看到标准这么多没精力逐条确认所以不投;没责任心的人看着条目差不多符合流畅、遵循格式手册、长度合理就直接给支持票了。审议制度将典范条目标准进行足够细颗粒度的审视,有能力的人只要专心检查是否专业、是否与来源对得上号即可,专业能力欠缺的人就去检查行文是否流畅,格式是否得当等不需要专业知识的准则。将审核过程分工完成降低了所有人的负担,或可形成能力门槛降低的效果,更有亲和力。协调员是守门员,对他们的要求应当较高。 --MilkyDefer 2022年10月7日 (五) 11:37 (UTC)
    • 我担忧的是,实施初期可能会有编辑秉著改善中维的决心去审视各提名条目,这当然是好事,但日子久了,参与人数或会稳定下降,最后典范条目评选重回多年前投票附理由的情况,即“内容充足、语句顺畅,参考资料足以支撑全文,以支持票作奖励。”之类。--银の死神走马灯剧场祝你在乱流下平安 2022年10月8日 (六) 10:14 (UTC)
      不一样,如果害怕有这种现象就应该不允许投票带理由,而是给每一个条件打钩或给予评价,这样迫害捣乱评选者的时候就不可以以忘记了有这个规定的理由逃避迫害。--0xDeadbeef留言2022年10月8日 (六) 10:33 (UTC)
      共识制评选的规定中,如果“评审员没有提供足够的信息来判断条目是否符合标准”,协调员可以判落选。
      此外,虽然共识制在中维可能做不到完美,但能避免投票制中的不少问题:比如不读条目就投yesFA(甚至我看到有提名人请求撤销FA时,都有用户上来就投yesFA……)、高质量的条目因为规定时间内少几个人投yesFA而落选等,我觉得总体而言共识制仍是一大进步。--BlackShadowG Slava Ukraini! 2022年10月8日 (六) 14:39 (UTC)
      • 我只是觉得,优良/典范条目评选引入所谓“英维式共识制”的确能够隔绝劣质条目,但我对中维有没有足够审核人评核条目这点有所保留,毕业大家都是义工,吃力不讨好的事没有太多人愿意做,而且会长篇大论指出条目各项错处误译的编辑也走得七七八八。--银の死神走马灯剧场祝你在乱流下平安 2022年10月9日 (日) 03:55 (UTC)
        • 这个是评委本身的学养问题。遗憾地,三个臭皮匠取代不了诸葛亮。然而,在最好的情况下,臭皮匠可以当个好助手,让诸葛亮专心发挥所长,不用管官僚程序和低级问题。--Temp3600留言2022年10月9日 (日) 09:19 (UTC)
          倒过来说,这种预审的好处,就是可能将臭皮匠们的权限压缩在格式、来源一类的问题上,让诸葛亮对内容的意见能够突显出来。然而,到底有没有诸葛亮,这才是最根本的问题。-Temp3600留言2022年10月9日 (日) 09:23 (UTC)
    • (:)回应:拆分FAN的审核流程可以算是一种预审。MilkyDefer上面的解释很好,然而并没有解决核心问题,即对内容本身的审核问题。换句话说,折毛的FA是奇状怪状的不良产品,日后有了预选后,至少可以产出金玉其外的不良产品。这或许是一个进步,但将其美名为“英维式的共识制”可就差远了。--Temp3600留言2022年10月8日 (六) 13:58 (UTC)
      我认为不管你如何想,有进步比原地踏步要好。如果能够透过改善一下优质条目整体水准的方式吸引一些学者来(而不是对英维趋之若鹜、对中维嗤之以鼻)的话,就更好了。--MilkyDefer 2022年10月8日 (六) 15:20 (UTC)

方案设定

那就这样,我先草拟一个方案,如下:

  • 在该方案得到公示通过后,试行一次有效的评议制典范条目评选。
  • 上一条当中的“有效”指的是,条目不满足快速落选准则,且不是典范条目重审。
  • 选择的评选条目应该是在公示通过后,所提交的第一条典范条目评选。如果该候选条目不是有效的评选,则选择确定候选条目评选无效时刻起,下一条提交的候选条目,以此类推。
    • 例子:假如本方案于2022年11月1日凌晨3:47公示通过,同日凌晨4:13有人提交了条目A作为典范条目候选、上午9:24另有人提交了条目B、下午17:33有人提交了条目C。则条目A成为试行评议制的对象,条目B和条目C继续使用投票制。但是,在11月2日上午10:41时有人发现条目A含有大量侵犯版权的内容而导致其快速落选(参见即时不合标准准则第2条),则这一次对条目A的评审为无效评审。由于条目B和C已经在走投票流程甚至有人可能已经投票了不适合打搅,因此应当选择11月2日上午10:41后提交的第一条典范条目候选作为新的审议对象,以此类推。
  • 该次使用审议制的评选,其结果拥有与现行投票制同等的效力。即,若审议为入选,则条目获得典范条目资格;若审议结果为落选,则条目同样落选,30日冷静期同样适用。
  • 应该为该次试行开设评审专页,同时在典范条目评选主入口提供进入该次评审专页的链接。(这一条是为了防止评议发言过多影响其他条目的评选,可再做商议)
  • 该次试行的协调人由我担任,毕竟是我提出要试行一次的。
  • 试行结束后,我们继续讨论后续事宜。

如何?我还遗漏了什么要点吗? --MilkyDefer 2022年10月2日 (日) 09:40 (UTC)

作为提案发起人表示原则性(+)支持,唯我另发起了一个二十周年闭站抗议提案,可能时间上容易冲突--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年10月2日 (日) 09:47 (UTC)
基本上思路可以,谨表(+)支持。不过应该需要另外开启草稿版面,放置排版一下先吧,看上去一些细节也需要梳理一下,包括那个轮候递补位列最好再看看怎么排一下先。--约克客留言2022年10月2日 (日) 11:56 (UTC)
@Longway22 所以具体而言有什么意见吗?你说的这些太宽泛了完全不懂。--MilkyDefer 2022年10月7日 (五) 03:15 (UTC)
在准方案讨论版整合一下吧,主要一个是对可能进行试行标的对象(即被评价条目)遴选机制作一定清晰化。--约克客留言2022年10月7日 (五) 10:40 (UTC)
没意见。--0xDeadbeef留言2022年10月2日 (日) 12:02 (UTC)
(+)强烈支持,我可以帮忙做一些准备工作。--BlackShadowG Slava Ukraini! 2022年10月2日 (日) 14:05 (UTC)
(+)强烈支持:不错的决策!!----👻Cryberghost 2022年10月3日 (一) 03:50 (UTC)
(+)支持--——🦝英特浣熊耐尔 就一定要实现留言贡献 2022年10月4日 (二) 04:15 (UTC)
(+)支持。 --窝法乙烷 儿法梦碎 2022年10月4日 (二) 08:13 (UTC)
基本(+)支持。--在下荷花请多指教欢迎签到2022年10月5日 (三) 09:55 (UTC)
(+)支持——一只星步甲|留言|签名 2022年10月5日 (三) 16:45 (UTC)

筹备

我开始筹备了:Wikipedia:典范条目评选/共识制试行,目前在翻译英维的规则。——BlackShadowG Slava Ukraini! 2022年10月7日 (五) 04:46 (UTC)

目前英维相关规则/模板翻译进度:
  1. 主页面:Wikipedia:典范条目评选/共识制试行en:Wikipedia:Featured article candidates完成
  2. Template:FAC-instructionsen:Template:FAC-instructions完成
  3. Template:FAC/共识制试行en:Template:FAC完成
  4. Template:Featured_article_candidates/共识制试行en:Template:Featured_article_candidates完成
  5. Template:Featured_article_candidates/editintroen:Template:Featured_article_candidates/editintro完成
  6. Wikipedia:Featured article preloaden:Wikipedia:Featured article preload完成
  7. Wikipedia:典范条目评选/存档方式en:Wikipedia:Featured_article_candidates/archiving完成
下方的页面在试行阶段并非必须,可以等正式改用共识制后再翻译/引入:
  1. User:FACBot(维护FAC的机器人,主要的工作是存档已关闭的提名)
  2. Wikipedia:典范条目评选/急需评审en:Wikipedia:Featured article candidates/FAC urgents
  3. Wikipedia:典范条目评选/入选记录en:Wikipedia:Featured article candidates/Featured log)入选的FAC由协调员加到这个页面
  4. Wikipedia:典范条目评选/提名存档en:Wikipedia:Featured article candidates/Archived nominations)落选的FAC由协调员加到这个页面
下方的页面可有可无:
  1. Wikipedia:典范条目评选常见问题en:Wikipedia:Wikipedia Signpost/2008-04-07/Dispatches)FAC的常见问题,没有也问题不大
  2. Wikipedia:典范条目统计en:Wikipedia:Featured article statistics
--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 08:42 (UTC)
此外@MilkyDefer:英维提名FAC评选的方式是让提名人往条目的讨论页上放{{subst:FAC}}(目前中维的模板位于{{subst:FAC/共识制试行}}),随机抽条目可能在程序上会与正式的不太相同。因此,比起抽一篇“幸运条目”用共识制,要不让有意让条目以共识制评审的主编自荐条目?--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:32 (UTC)
我们实验的是审议制度,在审议之外的流程性质的东西不在实验范围啊。--MilkyDefer 2022年10月8日 (六) 05:31 (UTC)
OK。--BlackShadowG Slava Ukraini! 2022年10月8日 (六) 12:17 (UTC)
目前基本筹备已经完成,随时可以开始试行。--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:49 (UTC)
据说要公示--0xDeadbeef留言2022年10月7日 (五) 09:54 (UTC)
建议用GA做试行,个人认为FA非常不适合用审议制。另外建议协调员至少三人而非只有一人。--2022年10月9日 (日) 20:07 (UTC)
能具体阐释一下你认为GA比FA更适合的原因吗?协调员的话一下子三个人就协调试行的一篇条目会不会多余了些?--MilkyDefer 2022年10月10日 (一) 01:12 (UTC)
FA是要多数社群认定的条目,GA则是在该主题内(换言之,FA跟GA的定位并不完全一样,如果一样为什么要分),我不认为区区几名支持者就能代表多数社群的意见(FA的标准本来就应该比GA高了,不存在所谓标准太高而导致选不上的问题,选不上是因为品质不够好),但我的确支持GA应该采审核制,毕尽有一些主题的条目就是不会引起很多人有兴趣去读,自然票数也会比较少。--2022年10月10日 (一) 01:40 (UTC)
有一个问题。你为什么会认为FA是多数社群认定的条目?可能确实需要比GA多一点的人认同,但是夸张到多数是不可能的。在英维平均一个GA的审阅者1到2个;FA大概10个,怎么看都不是“多数”。要追求你想象中的多数,任何一个地方都没有。--MilkyDefer 2022年10月10日 (一) 03:14 (UTC)
我的意思是FA跟GA的根本不同在于GA是写“怎么样能够把内容或知识传达给读者”,而FA是写“什么样的内容或知识读者会有兴趣”(一言以蔽之:FA跟GA的不同就两个:解释行话和去芜存菁。要读得懂,也要读了之后会对里面提到的内容有兴趣,进而自行去做更多研究)。之所以不会同意用审核制是因为一篇FA应该要能足够吸引人去让编辑去支持一篇条目成为FA(都吸引不了编者了,怎么吸引读者),而非少数人自行决定一篇条目是否适合大众阅读(用站内的说法叫“适合成为FA”或“符合FA标准”)。如果还是不懂的可以去看6+的用户页来理解为什么他写FA写的很开心。--2022年10月10日 (一) 05:57 (UTC)
题外话:我能理解社群已经开始将FA跟GA慢慢有画上大概等于的感觉,认为“FA只是更好的GA”,这里有必要划清FA跟GA的不同。--2022年10月10日 (一) 05:57 (UTC)
FA并不是一定要为了让读者感兴趣。只能说是百科全书里面最优秀的条目,而往往很多优秀的条目都是能够让人感兴趣而已。
另外,感谢你的回复,解析失败 (带有PNG备选的SVG(MathML可通过浏览器插件启用):从服务器“/mathoid/local/v1/”返回无效的响应(“Math extension cannot connect to Restbase.”):): \int 。--0xDeadbeef留言2022年10月10日 (一) 06:00 (UTC)
我能理解的确有些读者读完了FA之后还是会对该条目的相关内容没有兴趣,但起码这是做为每位尝试写FA的编辑都应该要牢记在心的事。另外说真的,“百科全书里面最优秀的条目”是由谁评断?个人认为这只是句很模糊的话,没有什么实际意义。如果这个问题硬要讨论下去的话我会说是由整个社群来评断,但总不可能搞成像RFA那样有劳整个社群来评价一位候选人吧。--2022年10月10日 (一) 06:07 (UTC)
所以才会有典范条目标准,将“最优秀的条目”的标准明确化。--MilkyDefer 2022年10月10日 (一) 06:10 (UTC)
我并不认为当前标准足够明确(此句同样套用GA),仍留有许多供解释的空间(注:这并不一定不是坏事)。
而且我不认为也有需要依此延伸下去的必要。我并不觉得将标准明确化(或模糊化)对当前提案有任何直接的影响/帮助。--)dt 2022年10月10日 (一) 07:37 (UTC)
讨论状态:普遍相信采取审议制度可以相比于投票制度拥有更严格的把关。
现在事实:典范条目在品质上要求更优于优良条目。
所以不对典范条目严格,反而对次一级的优良条目严格,不符合直觉。--MilkyDefer 2022年10月11日 (二) 12:58 (UTC)
不见当前讨论对“审议制度可以相比于投票制度拥有更严格的把关”达到共识。相反的,许多人认为审议制可能并不适合中维,如Benevolen提到的“标准弹性很大”和约克客提到的“相关条件之现实门槛还需更多补足”--)dt 2022年10月11日 (二) 17:09 (UTC)
重申一次:我认为试行是可以的,但需要改善两点
  1. 改用GA进行试行
  2. 至少三人作为协调员/共识执行人。--)dt 2022年10月11日 (二) 17:12 (UTC)
我可以肯定,“审议制度可以相比于投票制度拥有更严格的把关”这句话所言绝对非虚。
如果说审议制“标准弹性很大”,那我可以说,投票制的所谓标准几乎可以视而不见。目前投票制是否入选不是依据“条目符合多少FA标准”,而是“多少人认为条目符合FA标准”。投下支持票的人可能没有读过条目,甚至可能知道FA要符合哪些标准,只要一定数量的用户投下支持票,条目就能入选,没有人能确定投票者是否有仔细审过(甚至是否审过)条目。即使有用户指出条目存在不少问题,只要支持票足以盖过他,那这些意见也可以视而不见。改用审议制度可以最大程度避免这种问题,至少审议制度中,仅仅表示支持是没有意义的。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:40 (UTC)
这样子说吧,请问你对于试行一次究竟有什么意见呢?改成GA和三个人总要有理由吧?英维的巨大RFC也只找了三个closer。如果和这个比起来是不是英维应该找三倍以上的人呢?不是说中维缺人吗?可现在一个无害的试运行都要求这么高了。--0xDeadbeef留言2022年10月12日 (三) 13:49 (UTC)
三个人的话是依当前中文维基百科社群运作方式(尤其是评选)提出的最优解。我觉得不应该只寻求完全照搬英维规则,而是想办法如何让一个具有建设性的新机制在不造成过大风险(即协调员本身的三个问题:协调员自身可信度/是否值得社群信任、如何对可能的错误判断负责〔是否协调员应该辞去该职〕及如何处理因改为审议制而造成其他可能的未知争议)的情况下融入社群。尤其是第一项(协调员自身可信度/是否值得社群信任),若是无法得到社群信任极有可能造成争议,变成遭人诟病的站务。
就如同之前的HAM,现在评选(起码FA)没什么问题很大程度就是因为是:
  1. 很简单的加减乘除,几乎不可能有人为操作空间。DYK、GA我不知道,但我长期关注FA,知道投票的就是那几个人,多数时候也就只有那几人投票,没有拉票的问题。至于FA选不上的问题前面解释过了,这里就不多提。
  2. 规定明文写出(几票就几票,少数服从多数),没有可以造成争议的地方。
  3. 所有参与者都享有同等地位,不会有人需要决定共识是什么,也自然不会有可信度的问题。
WP:没坏别修。随意完全引入(甚至只有部分)其他维基百科的机制并不一定对本地社群有益,反而有可能会造成更大的问题。虽然我自己也不是很喜欢见到本地不断引入其他站的方针/指引来创建出新的职位(之前是调查助理、现在是协调员),但我也不会全然否认该方案可能的益处。这也是我部分(+)支持这项提案的原因,尤其考量到我对除FA评选外的认知并不全面,因此我对DYK和GA的部分不予置评。
另外即使是试运行也应该当成正式评选来看,不论最终会不会实施。--)dt 2022年10月13日 (四) 03:39 (UTC)
如果要三个人,那你对于协调员人选有什么推荐吗?在此次试行中,这些问题应该不存在吧。还是说,你觉得MilkyDefer没有社群信任/不可信?如果说FA评选没问题,那折毛事件如何解释?--0xDeadbeef留言2022年10月13日 (四) 04:11 (UTC)
阁下认为FAC“没什么问题”是因为FAC有硬性标准,不会引发争议。但FAC最重要的目的,逐一检查条目是否符合WP:FACR,在投票制中完全无法落实,理由已如前述(例如:参与者完全可以不看条目/不知道FA标准就投票让条目入选,少数服从多数可以让重要意见直接视而不见)。共识制度即使有争议,也可以提高FA条目质量的把关。阁下认为“没坏别修”,在我看来这是已经坏了,而且坏得很严重,折毛事件就证明了这一点。
此外我不认为三个协调员是适合中文维基百科社群运作方式的做法。中维本身就人手不足,判断共识还需要三个人才能做到吗?再者,协调员出现争议又给谁来判断协调员的共识?“协调协调员的协调员”?到头来判断共识的权利还是会落到一个人手里。--BlackShadowG Slava Ukraini! 2022年10月13日 (四) 15:34 (UTC)
首先,拿折毛事件来证明应该要施行审议制本身就是一个问题。若有时间去重新看当时评选的人会发现三点即使用审议制也无法解决的问题:
  1. 并不只有平时活跃于评选的人参与讨论,相反的,有许多不常参与评选投票资深用户(如河水、百战天虫)亦参与了讨论,且并没有参与讨论的人发现这个问题。
  2. 12支持,0反对,相信若是依所谓“判断共识”而非“利用常识”来执行评选的协调员来说协调员也会选择通过该条目。
  3. 当时并没有所谓“重要意见”点出条目的主要问题。
当然,假定新机制在过去的表现如何是没有意义的。只用单次的突发性事件来作为几乎完全改变当前体制(若是基于投票制作出改善,如提高当选所需票数那另当别论)的理由是没有需要也没有必要的行为,但就方案本身的想法我还是有一定程度的支持。
另外我对协调员的推荐不予置评,我虽然长期关注FAC,也熟知长期参与FAC的编辑,但我自认还没有足够能力去判别谁适合来判断共识。我也没有写我不信任MilkyDefer,我只是希望有更多协调员能交换意见。当然共识的执行人确实只有一位,但是在有争议的情况下多一两人供执行人咨询总是好事。--)dt 2022年10月13日 (四) 16:31 (UTC)
诚然,审议制未必能完全防止折毛事件的发生,但能很大程度进行避免。当时远东华人强制流配的FAC中,没有用户检查来源,由于是投票制,因此即使没有用户做来源检查,条目也可以入选。如果是审议制,就更有可能有用户根据WP:FACR做来源检查(英维的伪条目Bicholim conflict就是在FAC被查出来的)。
鄙人仍不认为结案需要三个协调员,先不提中维是否有这么多人力,判断共识一个人足矣。协调员就相当于FAC的管理员,如果AFD要两三个管理员才能结案,显然不是什么好事。且会引起争议的评选,显然条目本身也是有问题的,即使被判落选,完善条目过一个月再来评选是个更好的方式。--BlackShadowG Slava Ukraini! 2022年10月15日 (六) 07:55 (UTC)
另外希望有3人的主要原因是因为在共识不明确的情况下由一人自行决定可能没办法做出最佳的判定,所以是希望有其他人也可以作为协调员交换意见。--2022年10月10日 (一) 01:36 (UTC)
只是试行,必要性不大。英维这么大的社群也只需要四名协调员,一篇条目就是由一名协调员结案。需要注意的是,条目是否入选不是依据协调员的看法,而是依据审阅者的共识,协调员只是负责判断审阅者的共识。这就好比为何AFD只需要一名管理员就能结案一样。--BlackShadowG Slava Ukraini! 2022年10月11日 (二) 12:52 (UTC)
那如果一讨论没有明确共识的话该当选还是落选?另外AFD只需一名管理员结案也不过是在有明确共识的前提才会结案,不然通常会进到积压讨论,最后甚至无共识保留(不太确定这对协调员来说这套用到评选是当选还是落选)。--)dt 2022年10月11日 (二) 17:15 (UTC)
根据目前英维的规则,“没有达成条目入选的共识”就是落选;这与审议制的GAC区别很大,审议制的GAC是一名审阅者主要负责审阅,其它编者也可以发表意见,只要基本没什么问题,审阅者就可以评定入选,这比FAC宽松很多,所以我不建议阁下提议的用GAC试行。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:15 (UTC)
如果最终决断有疑,可以依托之前意见再讨论和重选,多名协调员得出的共识也未必是普遍、可靠的共识,共识始终可推翻。如同存废讨论的异议路径是存废复核。--YFdyh000留言2022年10月11日 (二) 18:35 (UTC)
现评选规定为一个月后才能重新提交评选,存废复核并没有限制必须要几天后才能提请复核。个人认为若只依协调员的决定将有争议的条目选为典范,则必须等待一个月后才有可能重选。共识确实可推翻,但若无法及时改变则无法避免原可避免的负面影响。
再者,讲难听一点,我始终无法剔除掉有偿协调员而引发争议的可能性。这也是为何我会倾向有多名协调员的原因之一。--)dt 2022年10月11日 (二) 19:57 (UTC)
如果决断并不违逆共识而只是偏颇,继续在客栈等位置讨论就好,然后再走重选手续。严重情况得到共识建议雪球以推翻决定,但争议议题就很麻烦。如果说的难听,我也无法排除两名协调员一同忽视共识或争议的可能性,以及协调员如何可信。--YFdyh000留言2022年10月11日 (二) 20:14 (UTC)
BlackShadowG回应后了我又看了一遍,我还是搞不懂为何需要有三个协调员。如果你认为协调员关闭讨论的是en:WP:SUPERVOTE,那是不是在暗示你不认可MilkyDefer对于共识的判定?协调员的主要工作只有两个:第一是判断讨论中有没有达成共识,第二是保证讨论没有遗漏掉WP:FACR,且在共识作为提拔FA时有合理反对的权利。但是,并不是说明协调员能在多半人反对的情况下强行推进到FA。--0xDeadbeef留言2022年10月12日 (三) 13:34 (UTC)
我可以简单地说,判断共识的工作最后肯定会落到一个人手中,这一点几乎不太可能改变。协调员是负责判断审阅者之间的共识的,如果要多名协调员对“判断共识”达成共识,那如果协调员间产生不同意见,又由谁来判断协调员间的共识?再设立一个“负责判断协调员的共识”的职位吗?我不认为这样一层层下去是件好事,让协调员作为那个判断共识的人,就足够了。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:52 (UTC)

建设性提议

试行本就是为了摆脱空想看到底好不好,试行提案还要提修正案争吵的话实质上就是延续了空想,因此我建议下面的修正案可以跳过去直接按原案试行一次-有困扰的话,就让魔女用魔法帮你排忧吧! 2022年10月26日 (三) 07:21 (UTC)

试行一次修正提案

鉴于上面有人强烈要求对这一次试行做出两点修订,特列如下:

  1. 一次试行改针对一次优良条目评选
  2. 增加这一次试行的协调员数量为三人

如果大家都没意见的话我也就从了吧。 --MilkyDefer 2022年10月12日 (三) 01:01 (UTC)

虽然觉得三个人评选优良条目很搞笑,但是如果觉得这样有意思,我可以当一个协调员--0xDeadbeef留言2022年10月12日 (三) 04:36 (UTC)
(-)反对:一人、FA比较好,如果从GA试行那还不如从NYK试行呢。--有困扰的话,就让魔女用魔法帮你排忧吧! 2022年10月17日 (一) 06:01 (UTC)
(-)反对:
1.英维GA的共识制评审方式与FA完全不同,GA通常是一名审阅者主要负责审阅,其它编者发表意见;FA则是需要多名审阅者达成共识,显然在中维先试行FA的共识制评审更为合适。
2.一篇条目只需要一名协调员判断共识,理由已在上方回复。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:08 (UTC)
  • 我还是更关注谁来进行内容实质评审的问题。一个看版和一堆看版效果一样。--Temp3600留言2022年10月14日 (五) 10:23 (UTC)
  • 我觉得GAC要3人负责“协调”过多了,FAC的话则没有问题反正另外两人都只是负责endorse。--银の死神走马灯剧场祝你在乱流下平安 2022年10月16日 (日) 08:45 (UTC)
那不然鉴于这次只是试行改成三人就算了,就作GA试行一人协调就好。--)dt 2022年10月16日 (日) 23:46 (UTC)
不建议改成GA试行,GA审议制是一名审阅者直接决定条目是否入选,不需要协调员。--BlackShadowG Slava Ukraini! 2022年10月17日 (一) 11:43 (UTC)
我觉得他可能想的是走出与英维不同的路子——GA审议,FA投票……--MilkyDefer 2022年10月17日 (一) 14:15 (UTC)
FA比GA标准更严格,却使用更宽松的投票制?怎么看都不合理吧。--BlackShadowG Slava Ukraini! 2022年10月18日 (二) 13:14 (UTC)
那把他召唤出来阐释一下吧@ATannedBurger--MilkyDefer 2022年10月18日 (二) 14:30 (UTC)
前面已经解释过投票制并不一定比审议制宽松,及FA不适用审议制的原因。--)dt 2022年10月18日 (二) 15:54 (UTC)

即使有使用者指出条目存在不少问题,只要支持票足以盖过他,那这些意见也可以视而不见

,这是少数服从多数,我不认为在评选(尤其是高阶评选如FA)需要有所谓共识执行员/协调员。FA评选现在没什么争议(就看上过客栈的次数基本就知道了,相信有许多需要更高权限〔如管理〕处理的站务上过客栈的次数/争议数比评选还多),那为什么要引入一个鸭子测试一望而知会造成争议的制度?前面也有提到用折毛事件来证明评选需要改革是不需要也没必要的行动。
评选讲究公开透明,而非多出一级似乎像权限的用户组来专门处理评选。上一个在中维这样做的最后上了客栈被公开审判至少两次了,我不希望评选也变成那个样子。--)dt 2022年10月18日 (二) 16:14 (UTC)
看了上面你提出“现在评选(起码FA)没什么问题很大程度就是因为是”三个观点,给人印象似乎是不愿走出舒适区,习惯了固有的小圈子评选(投票的就是那几个人)。
“少数服从多数”和“不会有人需要决定共识”过于理想化了。如下文提到现在评选员的标准是“自动确认用户”即可,而且这也是目前DYKN、GA、FA的标准。一样的评选员标准,也是票数积分,为何DYKN、GA就较多争议,是否有争议和评论制度好坏没有逻辑关系。DYKN、GA就较多争议更多是因为新人参与等更多,他们对格式行文用语不了解,所以条目质量不免残次不齐,潜在争议的可能性大。
如果英维这个比中维规模更大的社区,使用共识制没有问题,现在的制度试行并没有损失。折毛事件只是一个典型例子,深层的问题是现在DYKN、GA、FA都存在的“零意见支持票”,就算是方针也有因为没人仔细看就通过的情况。共识制就是希望“有人对审议结果负责”,其实就算不进行审议,现行机制是可以对任何获选GA、FA的条目提出复核,就算不试行这个制度,也可以变现组建复核审查小组,有条件进行拦截(如FA评选中,认为不符合标准,曲线将条目移交GA评选或复核)。--Nostalgiacn留言2022年10月19日 (三) 17:09 (UTC)
(+)支持“复核审查小组”,的确有许多可能连GA都不符合的条目因为水票问题而上了FA(就文笔而言,内容比较难发现,详见现在在FAC进行的重选)。另外个人也建议在一条目得到FA提名前必须先有GA。
(...) 吐槽:这不是舒适圈的问题,而是有没有足以信服的专业人士(如写过多条FA,个人认为10+条为佳,并清楚知道FAC应该如何运行的编辑)来监督的问题,但根据现状时不时有反对权威(如“滥权管理员”一类)的事件发生,不建议引入“权威人士”来决定共识。--)dt 2022年10月19日 (三) 20:03 (UTC)
个人对“复核审查小组”在FAC的角色理解为:检查各条目是否即时不合规,且只有在即时不合规的情况下才可行使“落选权”。当选方式仍采用投票制,若一条目即使符合标准但未达一定票数仍落选。另外还是同一句话,我对GA跟DYK的相关提案没有意见。--)dt 2022年10月19日 (三) 20:22 (UTC)
看来我需要明确(-)反对现行的投票制。恕我直言,“没有争议”不见得是什么好事,阁下觉得投票制没有争议,那是因为目前的投票制中审阅者不需要仔细检查条目就能入选,“争议点”都不被发现当然“没有争议”。FAC的目的是检查条目“符合多少FA标准”,而不是投票制依赖的“多少人觉得FA符合标准”。即使“复核审查小组”也无法完全解决这个问题,很多条目的问题不是“即时不合规”,而是有不少问题以至于未达到FA标准,这不是增加一个拦截“即时不合规”条目的小组就能解决的问题。--BlackShadowG Slava Ukraini! 2022年10月20日 (四) 03:08 (UTC)
(!)意见承Black阁下所言之,关联衍生之似乎为评审方面,在现行情况下,其投票体系和小圈子编组等特定问题本身即有所争议,
可能研究对应之监察或复核机制等,修正需明示当期参与之个体统计数之地位、以及评审组定论之标准地位,列明相关地位在有关特定情况下,必须基于条目内涵或专业等差异而对应调整当期评核检视之尺度,并约定如需采用特定成员编组化之复核等措施、必须不抵触到条目内涵或专业等本身所具之合乎其内涵或专业等之采编知识尺度。
以上为暂定所建言之,谨供共议。--约克客留言2022年10月20日 (四) 03:19 (UTC)
关于这点“目前的投票制中审阅者不需要仔细检查条目就能入选”我还请您举证,因我不见有这类情况发生。折毛事件上面有解释过了,并不是水票的问题,而是当时社群绝大多数都无法辨别该条目的假资讯。这个问题自认用“复核审查小组”即可解决。
另外“FAC的目的是检查条目‘符合多少FA标准’,而不是投票制依赖的‘多少人觉得FA符合标准’”本身就是一个奇怪的比较方式。若一FA符合标准则其应符合了许多FA标准中列出的诸多标准,多人认为一条目符合FA标准反而让一FA当选更为严格。还有个人认为共识比标准更重要,若改为审议制势必限缩其他参与者在FA中表示支持一条目当选FA的能力。让决定和辨别共识从明文规定变成由“人”决定(协调员也是人,只要是人必定出错)并不是好事,所以重要的是风险最小化。--)dt 2022年10月20日 (四) 16:21 (UTC)
难道不觉得有点自相矛盾吗?你支持所谓“复审组”,并且承认有许多可能连GA都不符合的条目因为水票问题而上了FA,但却又认为现在的FAC没有任何问题。就算是投票没有问题,但此讨论中已经多次提到共识讨论制的优点和好处,而有人去反驳这些观点,并指出投票制相比共识讨论之下的优点了吗?我可不可以把现在讨论“FAC投票是否存在问题”这种无意义的讨论视为稻草人论证呢?说到最后,到底对于FAC试行一次、一个负责人有什么具体意见?难道你是不想看到共识制成功?还是你笃定共识制一定会失败?无论如何我都很疑惑为什么如此push back这个提案,而对我来说“不愿走出舒适区”都难以解释这种行为。--0xDeadbeef留言2022年10月20日 (四) 17:31 (UTC)
FAC就机制上而言是没有问题的,但不代表不能在这个机制之上建立其他能帮助这个机制运行更好的东西。对我来说,审议制相当于把评选“打掉重练”,且我也有指出“投票制相比共识讨论之下的优点”,并指出共识讨论的一些问题(如协调员独大,可自行决定共识、有偿协调员而导致协调员和评审员狼狈为奸、各评审员因其理据不同而在决定共识中不享有同等地位等问题),这些问题直到现在我还没看到令人信服的回应。另外有许多可能连GA都不符合的条目因为水票问题而上了FA亦是为何FAC重审机制存在的原因,并不冲突。
据我理解,复审组只能落选一条目,不能当选一条目。--)dt 2022年10月20日 (四) 19:48 (UTC)
“目前的投票制中审阅者不需要仔细检查条目就能入选”这点根本不需要我来举证吧,阁下觉得投下yesFA的编者一定仔细检查过条目了吗?再极端点说,一篇条目就算8名编者都没有看过条目投yesFA,条目照样能入选。
“FAC就机制上而言是没有问题的”这句话在大前提上就是不正确的,阁下认为FAC“没有问题”是说其“没有争议”,不用仔细检查条目当然没有争议。
至于您提到的共识讨论的一些问题(如协调员独大,可自行决定共识、有偿协调员而导致协调员和评审员狼狈为奸、各评审员因其理据不同而在决定共识中不享有同等地位等问题),我可以说,共识本身就伴随着争议,无论在互助客栈还是其它地方,只要有反对意见,争议就会存在,即使是让管理员来结案,也没法让所有人都信服。共识制FAC也是如此,有争议不是件坏事,这说明条目被仔细检查过才会引发争议,我也很乐于看到这种争议的出现。况且,有争议的条目其自身肯定也是有问题的,如果一篇条目收到大量的支持/反对意见,协调员再“独大”/“有偿”也没法改变既定的结果;真正会引发争议的只有那些支持和反对意见共存的条目,只有这些条目的结案会给协调员判断的空间,按照共识制的规则,这种条目通常会落选,在落选后的时间内,主编完全可以改善条目,把争议的问题去除再来提名,这是件好事。--BlackShadowG Slava Ukraini! 2022年10月21日 (五) 00:04 (UTC)
若是照您这么说,我并无法得知共识制究竟有何好处。您觉得现在投票制不行(也算是产生争议了,不然我们也不会在这里讨论),但共识制(据您所说)亦会导致争议,“因为共识本身就伴随争议”,造成之后还会有人在这里继续讨论共识制的争议/问题。
还有,我并非认为共识制在中维无法施行,但有足够理由相信共识制不适合当前维内风气(包括用户素质皆和英维非常不同,Sidishandsome这前面也有提到)、造成的麻烦可能比现有投票制还要多(可能的“滥权”、“不信任”等等,这我不列举,您可去看前面第一次提出时反对声浪有多大)且没有任何理据表明审议制能有效遏制折毛事件再次发生(您可以说英维有经验,但英维跟中维的社群组成并不一样〔最明显的:英维有arbcom,而中维没有〕,建议不要随便抄别人)。
一言以蔽之:弊大于利。另外以上这些并不是一次试行就能发现的问题,需要长期/反复的试行而有朝一日(肯定不是只有施行一个月,甚至一年可能亦有不足)才能施行。若是根本不知道什么时候以上问题才能看到解方则个人认为无需浪费时间。--)dt 2022年10月21日 (五) 03:13 (UTC)
@BlackShadowG:的观点其实讽刺地说出了投票制的一个重要优点:保证能够行礼如仪地完成评审。即使投票人全都是猴子,限期一到,总有一个结果,就可以照流程跑下去。搞共识制,就有争议,就有可能产生无结论的情况。如果找不到资深的主委来评断,评审就有可能无限延长下去,等待有才之士的出现。就行政来说,这当然不是什么好事。互助客栈和VIP就是这类长期无结论案子的集中地。--Temp3600留言2022年10月21日 (五) 14:11 (UTC)
如果从一家产出“条目”的公司来说,“照流程跑下去”的确是优点,但是维基百科不强迫任何人参与,又没有KPI,就算有着超越英维的宏愿也只能算个人口嗨。从认真做内容,保证FA的确符合“维基百科条目之杰出典范”的角度出发,投票制不够好,审议制值得尝试,也是负责任的做法。
个人目前最多只评选过GA,也只参与了解的内容的评选。不过我也看过一些FA评选充满争议的情况,让我以紫式部的FA和GA评选为例。“紫式部”进行过两次FA(落选),一次GA评选(通过),FA都因为Jarodalien的评价落选,而且Jarodalien发言之前,都获得一定的“零意见支持票”。GA那一次获得6个“零意见支持票”,个人发现有很严重的翻译问题参与到讨论中。
写在最后,维基百科不保证其内容正确无误,甚至也没有义务去“修改错误或者参与到非正式的同行评审”。从这个角度出发,投票制的确很好,反正错了也不用负责。--Nostalgiacn留言2022年10月24日 (一) 06:14 (UTC)
一人一票制与平等思想密切相关。至于齐头式平等是否良好制度,人人负责是不是就等于人人都不负责,就是另一个故事了。--Temp3600留言2022年10月25日 (二) 12:20 (UTC)
  • 问题还是实质评审:协调员作为主评审员,必须有足够的学养,才能在其他评审员意见不一时选出更有道理的一方,正如法官本身必先是优秀的律师。如果希望推动评审制,现在是应该寻找人才,准备通讯名单,并思考那些主题可以找谁来当主委,而不是讨论主席团要有多少人:一个看版与一堆堆看版效果一样。--Temp3600留言2022年10月19日 (三) 11:11 (UTC)
    GA和FA现在的评审员要求是“编辑注册7日且编辑次数达50次的使用者”,本来就很水了。--Nostalgiacn留言2022年10月19日 (三) 15:00 (UTC)
    是否因应在当期评审个案之情,对应设立通识提问之简易遴选流程?--约克客留言2022年10月20日 (四) 03:21 (UTC)
    可以考虑在评审的时候临时召集一两位熟悉相关领域条目编写的编者征取意见,就像你之前提到的,臭皮匠和诸葛亮的情况。常驻协调员要处理所有的评选条目,临时召集来的编者只需要在相关领域的评选出现时才来,协调员是投入(commit),其他评审含被召集人是参与(involve)。如果你要说会这个方向的编者只有提名人的话,其实在论文同行评审中最最冷门的方向也是差不多的情况。--MilkyDefer 2022年10月21日 (五) 02:20 (UTC)
    那万一那段时间专家没有上线那怎样办?以中维的人手,其实只能靠行政排班表来补足:接到评审要求后,先由普通评审员预审,排除格式、来源问题,然后预约主委来诊症。要是没有医生来,或者抢不到号呢?那就只好回家继续等了。--Temp3600留言2022年10月21日 (五) 14:21 (UTC)
    如果没有主审的情况下,可以让协调员按现有意见来判断,这就等于书记兼任主席,那可比现在的投票制糟糕多了。--Temp3600留言2022年10月21日 (五) 14:24 (UTC)
    条目评审也不是搞得这么等级森严的吧?熟悉该领域的编者也不见得需要与其他编者要具有某种上下级关系;所谓的协调员,或者说,召集人,发出邀请让他们得知有他们可能熟悉的条目在进行评审。不见得他们就会成为听取下面普通评审员汇报工作的那种“主审”。但是他们的意见可以给协调员很重要的参考是不错的,有熟悉主题的人的认可的话,协调员做出判断也会更有把握一些;熟悉主题的人长期不出现的话,评审就会被拉长,要么更多普通人加入审阅提高置信度,要么这种“专家”出现。考虑到现在英维的FA最久的能拖三个月,可以预见这种事情会发生但是不太至于会导致灾难。FA评选数量本身就比较少,姑且是还能经得起这种延迟的。--MilkyDefer 2022年10月21日 (五) 14:54 (UTC)
    MilkyDefer说得很好。然而社群是否愿意接受一场FA办三个月?--Temp3600留言2022年10月22日 (六) 14:54 (UTC)
    这个问题我不能替代社群回答。目前而言我是能接受的,我不能替代大家的看法。等其他人怎么说吧。--MilkyDefer 2022年10月22日 (六) 15:20 (UTC)
    我也能接受,FAC的所需时间的变长也代表着FA的评选标准以及条目质量的提高。再者,难度有哪家期刊同行评审几天就能完成的吗。--BlackShadowG Slava Ukraini! 2022年10月23日 (日) 02:27 (UTC)
    回复一下两个评论:
    保证能够行礼如仪地完成评审。即使投票人全都是猴子,限期一到,总有一个结果,就可以照流程跑下去。搞共识制,就有争议,就有可能产生无结论的情况。如果找不到资深的主委来评断,评审就有可能无限延长下去,等待有才之士的出现。就行政来说,这当然不是什么好事。互助客栈和VIP就是这类长期无结论案子的集中地。
    MilkyDefer说得很好。然而社群是否愿意接受一场FA办三个月?
    目前的论点是关于所谓“个别条目在审议制中产生争议”的问题。对此我有以下几个回复:
    1. 既然这种无结论案子这么多,意思是VIP和互助客栈也应该投票制吗?这种论证很奇怪,因为在我看来,维基百科是不需要持续产出FA的。FA到最后不就是一个条目右上角的一个五角星吗?但是如果把中心放在“FA产出效率”上,那是不是就是想要引发FAC体制内的编者的反对呢?从我第一个问题应该就能看到这种比喻的问题了吧?共识制所谓的“无结论”情况指的是“no consensus”的结果,而对我来说,能把一些原本是noFA结果的条目变成no consensus是一个改善,因为它能告诉编辑条目在于yesFA的边缘,而更多的改善则能够临门一脚进入FA范围。而对于把原来yesFA的结果变成no consensus,请看第二点。
    2. yesFA变成no consensus问题:从结果导向的角度来看的话,FA产出变少确实是不好的,但是这也可以说明社群对于FA的评选标准增高了。其实你要如果说这种转变会把原来完美符合FA标准的条目变得no consensus,那就是在变相地说“中维FAC参与者都是猴子”这种假设是在某种层面上成立的。
    3. “FA办三个月”问题:这其实比较矛盾,因为对于共识制的另一个不同意的观点是在于“英维的东西不全适用中维”,而提出这个问题则是在隐性地将enwiki和zhwiki画上一个等号。并且,如果你说FA可能办到三个月,是什么原因造成的呢?我目前能想象出来的就是讨论太耗时而投票没有那么耗时,所以共识制讨论会更长时间。但这不就代表使用共识制会更完全的对于一个条目是否符合FA标准进行评测吗?之前有人否认投票制的人不好好检查条目和FA标准就投票的问题,但是如果说投票制的人都很好地检查FA标准而投票的话,那不就说明共识讨论制和投票制应该需要相同的时间吗?
    --0xDeadbeef留言2022年10月22日 (六) 15:29 (UTC)
    若要讨论no consensus对评选的影响应该这么说,no consensus给人的感觉就是“不知道什么原因而没有达成共识”。相对的,有一个明确的“入选”或“未入选”比较不会导致争议(入选或没入选肯定是有原因的)。若您也要做投票制和共识制在其他领域的比较,那为何RFA不采用共识制呢?我并不认为拿其他站务(而且类型还非常不同,那些站务是要剥夺编辑权限的站务,一次评选又不是剥夺条目入选资格)来比较是一个洽当的评判标准。正如WP:RTRL,别人闯了红灯,但那人是警车执行公务啊。
    其实现在有没有足够的投票人数就另类形成所谓no consensus了,即沉默的反对(不想得罪人,但又不支持条目,免得搞得跟Sanmosa和6+一样撕破脸),这在FAC尤其常见(这也是为何我不认为英维规则适合中维,习惯差太多了)。就如最近我修改了一篇GA后投了FAC,不少常驻FAC的编辑(如SickManWP)没有投yesFA(但也没人投noFA),我是在私底下问才知道问题的(有人觉得红链太多,有人觉得可以翻得更好)。重点是我并不认为协调员可以侦测出/发现各编者对一条目的见解。
    我认为每个人都有权表示支持、反对或所谓“沉默的反对”,不论有没有道理。就我看来,共识制将形成另类如同互助客栈的辩论平台(即哪方比较有理),而这并不是好的现象。强制征求编者意见可能长期来看会损害各编者之间的关系。
    另外再回应一下三个月的问题,我个人认为不是时间的问题,而是那位敢放在FAC三个月的编辑的问题。既然明明知道没有共识上FA(不然也不会积三个月)是不是应该先撤回,改善后再重新提名呢?我认为除非是那类非常固执的编辑(到目前为止我见过最极端的是6+,但他也不会因为一次、两次、三次投票没上而在那边有怨言),不然应该也要明白一个人占掉FAC三个月的资源是非常自私的行为。--)dt 2022年10月25日 (二) 03:28 (UTC)
    所以你觉得沉默的反对比能在共识制上评论好吗?现在的投票制本来已经边缘化那些不投yes或no而只想评论的人了。至于若您也要做投票制和共识制在其他领域的比较:是Temp3600先说互助客栈和VIP就是这类长期无结论案子的集中地我才回复的。关于RFA采用共识制的问题,我个人认为能采用是好的,因为英维也采用共识制。并且如果你读一下你维的WP:RFA界面也能看到行政员负责在管理人员申请程序结束后,依照共识赋予当选人管理员或行政员权限。此外,行政员负责在困难的情况下决定投票共识及结论,所以一直以来是你觉得RFA就是超过百分比就自动通过吗?至于你举一个你认为比喻不当的例子就能证明我的比喻不当的论证我无语了。我已经决定不再对你的评论回复,因为你的这些评论在我看来和“为了反驳而反驳”而不是真正考虑别人的意见,并且我继续回复没有任何意义。我也不指望你维能因为WP:NOTBURO作出哪些改变,之前的一个在跨维基活跃的用户早已从所有项目隐退了,我看我单一专注英维也是迟早的了。--0xDeadbeef留言2022年10月25日 (二) 05:10 (UTC)
    那好啊,比中国人更看重人际关系以及读空气的日本人他们的制度又是什么呢?
    • 支持票通常都带上长篇大论
    • 投票持续最长三个月,特殊情况可延期一个月
    • 在上述期限内的任意时点达成“支持票三票且占有效总票数四分之三之上”的状态且持续一个礼拜即告入选。
    • 满足下列任意情况者快速落选:
      • 反对票至少三票且维持一个礼拜
      • 没有其他支持票且提名者撤回提名
      • 提名者是傀儡账号被不限期封锁,没有其他支持票
    现在论支持票是投一个yesFA走人,又说不能走讨论制度,两边都取不到好,真的要成文明洼地了。--MilkyDefer 2022年10月25日 (二) 05:19 (UTC)
    我不认为“沉默的反对”在FAC中是需要考虑的(无论是投票制还是共识制),既然对被评选的条目有意见,就应该在评选中提出来,既然无意提出自己的意见,就不应指望自己没提出的意见被纳入考量。协调员没有义务侦测出/发现各编者对一条目的见解,他们只需要依据提出意见的用户做出判断。
    鄙人不太认同共识制将形成另类如同互助客栈的辩论平台这一观点,共识制FAC不是正方与反方的“辩论”,且与客栈和RFA有本质上的不同。共识制FAC是反方指出条目不合标准的地方,让主编来改善,只要改善完成,再多的反对意见都可以解决,而不需要正方来“辩论”。--BlackShadowG Slava Ukraini! 2022年10月25日 (二) 10:23 (UTC)
    先回应一部分:
    有部分站务的确使用投票方式决定结果,例如维基百科:投票/二十周年纪念识别标志就以投票方式产生。我无意详细讨论那种场合使用何种方式较有利,仅指出不同的决定方式皆有其优势。
    FAC的目的之一当然是引起编者的反对,以进一步改善条目。编辑者们积极提出意见正说明社群活跃,气氛良好。然而,世上没有免费午餐,所有制度皆有成本。
    举例来说,高考制度尽管有各种害处,在行政成本上有其重大优势:单凭一个分值就能处理大学分派,以致作为对一个人终生学术水平的评估。投票制尽管将猴子当成人看,在保证明确得出结果这一点上可是很优秀。
    我会将BlackShadowG的说话反过来理解:如果要提高FA的评选水平,评审时间就必须延长,这就是代价(之一)。目前的FAC能够在极短时间内处理某些冷门评审主题,正是将猴子当成人看,硬生生将no conenesus扭转成yes FA. 这不是什么好方案,但至少在行政上处理了问题。改成评审制很好,提高评审水平也很好。但谁来排班表?
    “英维的东西不全适用中维”,我觉得我们可以再悲观一点,如果三个月后评审都办不完要怎样办。在理想情况下,“共识讨论制和投票制应该需要相同的时间”。然而,投票制可以犠牲品质来换取速度;共识讨论制要么坚持等待讨论结果,要么将向独裁制转化。这可比投票制的问题严重多了。--Temp3600留言2022年10月25日 (二) 12:56 (UTC)
    能理解你的想法,感谢回应。在我看来我们的意见分歧应该在于品质和速度的权衡问题。之前也用过折毛事件作为例子,而想表达的并不是共识制便能够完全阻止这种事情的发生,而是说明共识制带来的潜在品质可以更好地去提前发现这些问题,而不用像折毛一样发现之后需要大量时间来清理打扫。也许这样相比之下,共识制也能带来省去一部分这种时间的好处。至于共识制是否能够真正带来更好的品质,这也是试行计划想要证明的一部分。--0xDeadbeef留言2022年10月25日 (二) 13:30 (UTC)
    可以补充:不单是速度,还有“稳定”。无论评审结果如何,只要努力两个星期,事情就总算结束了。比如说只有暑假有空的话,大可以在八月中前提交评审,保证在开课前完成FAC。--Temp3600留言2022年10月26日 (三) 15:23 (UTC)
    你说的对,但是我仍然觉得速度和稳定的问题都不大。共识制并不需要原来提交FAC的人在FAC的全程都跟进并且作出必要的改变。这和WP:OWNWP:CHOICE都不相符。共识制作为一个讨论的平台也许会激励其他用户在申请人Wikibreak的时候帮忙改进并提升至FA。我还认为,如果共识制的一个FAC在两个星期后都还没有结果的话,在投票制也不一定就能有结果。--0xDeadbeef留言2022年10月26日 (三) 15:37 (UTC)
    绝大部分情况还是主编按FAC的意见来改进条目的,长期不上线会有麻烦。--Temp3600留言2022年10月26日 (三) 15:44 (UTC)
    继续回应:
    “沉默的反对”是一个问题,但暂时没有什么好方法。我个人在这类问题上的见解是引入匿名发言。不说话,主编就算希望改善条目,也不知从何入手。然而,即使在目前制度下,编辑仍能通过意见及中立票来影响“选情”,在DYK中,基于同情票问题,不少编者都改用意见代替反对票,只有对方拒绝改善时才会投反。FAC中大家不写意见,只能说是懒惰了。
    至于“文明洼地”,这不就明摆着吗。如果诸君愿意投票时认真一点,严肃看待公民责任,今日何以至此?--Temp3600留言2022年10月26日 (三) 15:41 (UTC)
    最后(?)说点“建设性想法”:
    事实上,我确信这次试行将会成功。只要选择一个合适的时间,确保有足够的大佬愿意撑起场面,事先考虑评审条目的主题,要筹备一次FAC并不困难。困难在于日后千奇百怪的FAC出现时,评审制是否能够承接这些工作量。
    因此,这次试行的成果与全面推展共识制可说是没有关连,最多就是证明中维还是有一些认真的编辑者。
    目前而言,可以考虑将共识制拆分,仅于部分较活跃的专题组实行。比如ACG条目,MilkyDefer、Lopullinen等都可以当主委,要是没空,可以拉cwek、eric liu来,应不致出现主委旁落,被外行人掌握的局面。至于其他主题,保持现状为宜。--Temp3600留言2022年10月26日 (三) 16:01 (UTC)
    确实一次的试行和全面推展并没有关联,也不存在“因为试行成功所以应该拓展到整站”的理论,个人认为可以姑且一试。
    当然也应考虑试行后当选的条目是否仍要重走投票制。--)dt 2022年10月28日 (五) 05:39 (UTC)
@MilkyDefer:目前未见人反对原本的提案,而ATannedBurger也在上面说过部分支持。因为是试运行,还需要公示吗?--0xDeadbeef留言2022年10月26日 (三) 16:05 (UTC)
确实我们好像花了很多精力去解释可持续性的问题,但这跟仅仅一次的试行可以说是毫不影响。不过Temp3600说的也对,这次试行还是选择一篇相对熟悉的领域(对我而言是ACG与电脑)来审,而不是最开始设定的“无差别选择第一篇提交的条目”会不会好一些?如果试行的条目对领域存在限制的话,到时候我们就必须等待一篇相关领域内的条目提交到评选来,这个延时就不在可控范围内了。--MilkyDefer 2022年10月27日 (四) 10:14 (UTC)
那我们现在需要先决定选什么领域的条目吗?--BlackShadowG Slava Ukraini! 2022年10月28日 (五) 10:02 (UTC)
首先先决定要不要选特定领域的条目,再考虑选什么领域的条目。不管是ACG还是电脑技术哪怕是初等中等数学,被送上FAC都是稀奇事,说不定到年底都见不到一篇。--MilkyDefer 2022年10月28日 (五) 10:29 (UTC)
我觉得选不选特定领域的条目均可。不过如果需要ACG相关的FAC条目的话,我之前主编的最后生还者就是FAC不够票落选的,30天冷静期过去后我会重新提名,如果实在缺条目的话也许可以等这篇。--BlackShadowG Slava Ukraini! 2022年10月28日 (五) 10:48 (UTC)
也可以哦……只要不是原神相关。--MilkyDefer 2022年10月29日 (六) 11:25 (UTC)

关于试行一次的公示

已通过:
至少没有人反对要试一次,那就这么定了。MilkyDefer 2022年11月11日 (五) 12:44 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。

总之,在将近一个月的讨论(辩论?)当中,大家都中途偏离轨道开始讨论制度的可持续问题。这不应该成为试行一次的blocker。 公示7日

  • 兹试行一次有效的评议制典范条目评选。
  • 上一条当中的“有效”指的是,条目不满足快速落选准则,且不是典范条目重审。
  • 选择的评选条目应该是在公示通过后,提交的一篇落于ACG范畴或是电脑、资讯科技范畴的条目。(简化挑选准则,因为保底会有一篇最后生还者进行第二次典范条目评审)
  • 该次使用审议制的评选,其结果拥有与现行投票制同等的效力。即,若审议为入选,则条目获得典范条目资格;若审议结果为落选,则条目同样落选,30日冷静期同样适用。在社群的反对意见极大的时候,不排除入选的条目还要重新投票的可能(我希望这种事情不要发生)。
  • 应该为该次试行开设评审专页,同时在典范条目评选主入口提供进入该次评审专页的链接。(完成Wikipedia:典范条目评选/共识制试行
  • 该次试行的协调人为MilkyDefer

--MilkyDefer 2022年10月31日 (一) 05:06 (UTC)

  • 可以准备打包走人了。这个社群一定要至少先示范几十个存档,这样才能考虑要不要再用存档。不然就可以走退休了吧?看看最近一个月(2022年10月)以来,其他愿意帮忙用存档的似乎只有看见@SilverReaper而已,如上面所述,根本也见不到哪个管理员来出手,就人手而言显然就已经不够了。以后想要靠这个拿到站务奖的用户啊,难度一定升高了不少,因为真的是有看没有懂。如果没有示范存档的话,估计就是准备走向类似存废讨论一样成为积压的页面,因为都没人敢动存档。算了,反正对那些本来也就写不出至少GA等级的条目来讲那是真的没差,要不然为何每次写在DYK提名时都得强调“不考虑{{produceEncouragement}}、GA或FA”呢?因为条目和是否为一个GA或FA完全无关,GA或FA也就是一个条目而已,并不会因此变成多个条目。--Z7504非常建议必要时多关注评选留言2022年10月31日 (一) 14:46 (UTC)
    我其实没有读懂你这段发言的意思,尤其是与现在公示内容的关系。如果你要说存档的话,由于将要试行一次的典范条目评选是单独开设子页面,届时的“存档”就是将整个评选子页面移动到对应的位置,甚至无需移动页面,直接在{{Article history}}填写上正确的讨论页面位置就可。若能引入FACbot的话整个过程就是真的不需要人来干预了。就我做过的存档而言,存档过程很繁琐。用作移动存档的那个模板(我记得是叫{{移动存档}}吧)的使用晦涩不好理解,修改{{Article history}}也并非容易,这都拉高了参与存档工作的门槛。没有相应的操作指南,会的都会,不会的也不知道怎么学,所以会有积压。
    补充一下移动存档的门槛有多高。大家都知道被移动的存档都会有一行近乎是统一的提示:“本讨论移动自XXXXX,执行人XXXXX”。这是统一利用了{{移动存档}}模板达成的。但是,在使用这个模板的时候做的都是替换引用,因此从编辑后的页面源代码中是看不出讨论是如何被移动的。想要移动存档对不熟悉的人可以说是连门都摸不着。--MilkyDefer 2022年11月2日 (三) 13:38 (UTC)
    英维的en:User:FACBot就是专门处理存档的机器人,但是是共识制的,如果共识制的提案通过,也许可以引入这个机器人(原作者有公开源码,应该问题不大)。似乎目前的投票制也可能可以用机器人存档,不过这就需要请熟悉相关技术的用户来专门就中维的存档机制编写机器人了。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 14:19 (UTC)
    怎么不干脆说以后这些存档都不用手工存档就好了呢?全机器人、全自动化。呵呵,那就要保证存档绝对不会出错馁,怎么可能?啊如果机器人存档真的不会出错,真的能打包走人了啊,还需要普通用户在维基百科做存档干啥呢?也免了吧。当然,若以后交由给机器人存档提名,还可以完全避免掉“移动存档的人是提名人自己提名的条目”这问题呢,反倒是优点,因为解决了一小部分的Bug。--Z7504非常建议必要时多关注评选留言2022年11月2日 (三) 19:46 (UTC)
    emmm我是说有没有一种可能,存档机器人可以设计成只有在协调员下令要求其存档的时候才会运作?谁下令谁负责擦屁股这种道理应该是很明了的吧?--MilkyDefer 2022年11月3日 (四) 02:24 (UTC)
    英维本来就是这样啊……--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 10:27 (UTC)
    我想Z7504君其中一个意思是,虽然机器人存档可以避免之前提及“自己结束自己的提名”的风险,也省却了人力,但至少现时的人手存档机制是一个途径让用户接触站务工作(甚至获得维基奖励)。--银の死神走马灯剧场祝你在乱流下平安 2022年11月3日 (四) 12:27 (UTC)
    我不认为接触站务工作必须要跟机器人抢工作(当然我是说有机器人的前提下),而且中维有大量站务工作可以帮忙处理。--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 12:52 (UTC)
    刚好可以跟隔壁存废讨论联动一下,担心存档条目评选这份站务工作会被机器人抢了的可以去隔壁存废讨论积压解决{{Follow-up}}标出来的,已经有结论但没人执行的事情。--MilkyDefer 2022年11月4日 (五) 04:54 (UTC)
    机器人取代人类,将人类从低价值的重复文书工作中解放出来,不是百利而无一害吗。--Temp3600留言2022年11月6日 (日) 16:30 (UTC)
  • 想问一个比较尴尬的问题,如果公示期完结后无人自荐条目,而保底的《最后生还者》也没有可供协调员参考的明确意见(有机会发生的是一堆纯支持票,我在英维FAC也见过有编辑投这类),是否要等待下一条属于相关范畴的条目有兴趣参选FA才会再次试行?--银の死神走马灯剧场祝你在乱流下平安 2022年11月6日 (日) 03:22 (UTC)
    我个人认为要是这种事情真的发生了,那评审结束后我第一个要求回到投票制度。只有纯支持票跟投票有什么区别?反而还显得变成动态入选门槛。--MilkyDefer 2022年11月6日 (日) 03:35 (UTC)
    这个时候就考验主委的功力了。主委作为整个评审的召集人,除了自己需熟识有关主题,能发表意见引领众人思考外,也有邀请合适的编审者协助评审的职能。如果只有无用的纯支持票,条目旳状态就是“无共识”,须等主委邀请更多高明之士前来发表意见。--Temp3600留言2022年11月6日 (日) 16:30 (UTC)
  • @慕尼黑啤酒SuicasmoA1Cafel卡達:召唤一些(我印象中)时常提名条目参与FAC但未退休的编辑给予更多意见。--银の死神走马灯剧场祝你在乱流下平安 2022年11月7日 (一) 10:59 (UTC)
  • @慕尼黑啤酒SuicasmoA1Cafel卡達:我也来ping一次。在长达9天的公示过程中Z7504提出了一个很奇怪的意见后得到回应。我等到这周五晚上6点(UTC+8),如果没有其它问题的话就告通过了。 --MilkyDefer 2022年11月9日 (三) 07:55 (UTC)
    本人甚少参与站务讨论,恕难以给出建设性意见。站在主编者的立场,惟希望条目评选的流程简便顺畅为佳。--慕尼黑啤酒留言2022年11月9日 (三) 08:30 (UTC)

本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。

试行期间的交流

后续讨论

  • 条目评选也算是大致完成,我对全面推行审议制的想法是:本站做不来。—— Eric Liu 創造は生命(留言留名学生会 2022年12月12日 (一) 12:05 (UTC)
    为什么呢?共识制度从英维搬来应该是一个很成熟的流程。至于有些人觉得评选不能在一个指定的时间内通过是一个很大的问题,但是我觉得这是一个十分现实的trade off。典范条目应该是百科条目中最好的,所以当不应该成为FA被投票选成FA的条目被发现了,这件事应该责怪谁呢?在投票制下,貌似谁都不用负责任。而审议制则能够提供证据,能至少对于“为什么被认为是典范条目”提供一个答案。如果中文维基的平均编辑水平没有英维高,那更要进行共识讨论。如果说有八个自动确认用户觉得符合标准,所以就应该是典范条目的话,那么是不是说明FA的门槛比较低?--0xDeadbeef留言2022年12月12日 (一) 12:23 (UTC)
    (!)意见:简单来说,审议制FA太花时间及人力资源。
    在审议制试行的第一个星期,不同编辑者尝试提供意见(包括我),唯评审员只接纳2位编辑者的意见,有点不太中立。
    在第二个星期,我刻意不回答相关解决方案,因为现有的方针(WP:共识 )指出
    “另外,为确保讨论的连贯性,任何正当合理的意见(无论是否于公示前或公示后提出)若已获提案人正当合理的回应,且自该回应起计的3日后无进一步再回应,应视为该意见已解决”
    唯评审员仍然选择ping本人回应。换句话说,评审员花了大量时间关心FA过程。
    在第三个星期,评审员宣布最后7日提出评审,该意见表格没有更新。
    第四个星期,评审没有依从时间结束讨论。
    ——
    由此可见,一个评审已很混乱,评审员如何每月处理十则提名?--唔好阻住我爱国留言2022年12月12日 (一) 13:27 (UTC)
    首先作为第一次试行所以不可能所有都能第一次搞到完美。至于你刻意不回应我是觉得不能作为不试行审议制的理由。既然是同行评审那就要有一个互相交流的过程。至于评审员是否花费了“大量时间”,根据这些也无法判断。至于不更新表格和没有按时结束,也许你想表达的是应该换个评审员?--0xDeadbeef留言2022年12月12日 (一) 13:54 (UTC)
    首先,这不是评审员的错,因为回答人数在四星期内仍不足最低人数(9人),判断不出结果反而正常。换著是我以“收成期”价值观做评审员,肯定会有不少人表达不满。--唔好阻住我爱国留言2022年12月12日 (一) 14:08 (UTC)
    看起来阁下好像理解出了些问题,不同编辑者尝试提供意见(包括我),唯评审员只接纳2位编辑者的意见,这是因为这两位编辑者(我觉得您是指我和0xDeadbeef)有详细依照FA的标准检查哪一项符合,而阁下只是提出了两个问题,没有进一步说明阁下认同条目符合哪些FA标准,不符合哪些FA标准,阁下没有说明当然协调员也没法纳入考虑。你引用的WP:共识的那段条文是仅限于互助客栈的,FA评选不适用。意见表格没更新不是什么大问题,没有依从时间结束讨论不知道指的是什么。--BlackShadowG Slava Ukraini! 2022年12月12日 (一) 14:06 (UTC)
    • 难道“审议制”不是“共识”的一环?
    • 反而觉得评审员直接在表格中签名留下自己最关注的部分是最好。
    • 不是整点结束。
    • 第一条问题主要是关注标题是原创还是有根有据…
    --唔好阻住我爱国留言2022年12月12日 (一) 14:16 (UTC)
    第二个point是“编辑者”,非“评审员”。--唔好阻住我爱国留言2022年12月12日 (一) 14:17 (UTC)
    你就没注意到你引用的那句话是在WP:共识的“互助客栈”这个大标题下面的吗?那个表格只是为了直观说明,怎么用都没多大差别。“不是整点结束”……你觉得结束时间多准确很重要吗?你提出有关条目的问题是OK,但审议制更多需要将条目依照FA的标准检查。我觉得你的关注点过于细枝末节了,没什么值得注意的。--BlackShadowG Slava Ukraini! 2022年12月12日 (一) 15:11 (UTC)
    关于那个表格,“没有侵权”及“图片版权”部分,其实是可以引入turnitin 那类的机器人测试,一般编辑者不会一字一句上Google 检查抄袭率及版权问题,意思是在审议前筛走一些明显不合资格的条目,节省人力资源。--唔好阻住我爱国留言2022年12月12日 (一) 15:51 (UTC)

利益声明:1) 参与本次试行评审;2) 刷小作品的,没写过FA。

对于接近FA标准的作品,现在的评审生态多是直接给过,很有橡皮图章的倾向。本次评审中,多名编辑提出了翔实的意见,帮助文章迈向完美条目。因此,我认为这次试行是成功的。

但是悲观来看,我们还不具备遵照典范标准评审的条件:

  • 典范标准是很高的要求,是远高于优良标准的要求。以行文方面为例。GA只需语句清晰,但FA就要行文优美。因此本次评审中,即使对于表意清晰的语句,我也会提出润色意见。不过实践中,在句子表意明确的基础上,评审人是否有愿意继续提出意见,提名人是否乐于接受,这是一个问题。
  • 英维FAC之前有很多准备工作。例如英文版Fallout条目参选FA前就有1次GAN、1次copyedit、1次PR(同行评审)。其中GANPR中都有长篇意见。中维本次评审中,我注意到参选条目个别句子表意暧昧;而此类问题本是GAN中就应提出与解决的。尽管本条目直接参选FA,但即便先走GAN又能否解决这些问题,懂的都懂。而且对于翻译条目,我们比英维更需要copyedit,但可惜我们没有校订小组。因此,我们的FAC评审压力很大——不是提名者压力大,就是评审者压力大。

现行FA标准本站可能没几个人能hold住。在更容易评审的优良条目上套用这次的机制,或许还能降低评审人压力,鼓励他们严格按照标准评审,最终起到切实改善条目品质的效果。(至于为何更严谨的FA评选用投票?我认为我们的GA和FA评选严谨度没差,还不如改更有可能执行的那个。)--洛普利宁 2022年12月12日 (一) 16:47 (UTC)

感觉其实到头来最大的问题还是人力,即使我们使用英维一样的机制(GAN要求一名评审员认真评审,引入copyedit小组,提高PR的受关注程度),一篇条目按照这一套流程下来能得到的改善程度也比不上英维,但这也是没办法的事。
我认同在FAC前进行这一套提前改善条目的流程有助于降低FAC评审压力,这可能需要在FAC使用共识制同时,引入一些配套的措施,包括但不限于:修改GAN的机制,让编者在提名GA时就能让条目得到基本改善;提高PR的曝光度,鼓励提名者在FAC前先PR等。但无论如何,在人力的限制下,评审压力还是会存在的,速度和质量上也很难做到两全其美,例如如果跟以前一样用投票制,几天就能结束一个评审,但质量上没法把关;用审议制严格评审,就需要更多的时间和精力,这次评审有至少7人参与,耗时也达到了一个月。
至于“GA和FA评选严谨度没差”这个问题,虽然有WP:优良与典范条目标准对比,但事实上每个人对这两大评选的标准还是有一定的弹性空间。理想情况下,如果GA和FA评选都采用共识制,那么就有更多的机会来让评审员们达成“这个问题是GAN就需要解决的,还是FAC才要处理的?”这样的共识。但事实上主观因素还是会存在,比如假如我在GAC中说条目缺少某些内容,我可以以缺少这些内容就不符合GA标准的“涵盖面广”为由来要求主编改善;主编也可以说条目已经“涵盖面广”,那些内容是FA标准的“全面”才会要求的内容来反驳。--BlackShadowG Slava Ukraini! 2022年12月13日 (二) 12:32 (UTC)
我认为现行评审制度正是极度不符合人力资源现状。一方面是GA/FA的6/8人的评审制度,而英文维基连FA评审都不用6人。另一方面是水土不服的英维WIAFA标准:比如行文方面,大家都忙着写条目,提意见属于有能力没人力;而内容方面可能是连能力都没有,所以不是借英维评审东风,就是信任编者有知识储备(有时会炸雷)。这两方面导致品质标准形同虚设,实际评审集体摆烂。更重要的问题是,一代又一代的新维基人也学会了摆烂。(如今的评审品质和十年前相比几乎没有进步)我认为只有引入新模式,才能改变这种现状。(当然不一定是在FA/GA评审本身上改,也可以是PR,或者我在游戏专题简讯里提到的专题评审。但无论如何,关键还是要有人认真审,且评审过程受到社区尊重。)
我并不期望本站评审达到英文维基的品质。我甚至期望用en:WP:WIAGA作为本站典范条目的标准:用一个力所能及的目标,换取评审者的认真参与,达到实际改善条目的效果。毕竟八张零意见支持票的结果是,条目既没有得到改善,也未必符合字面上的FA标准。
当然,施行审议制终归是费时间。且不说上面讲的流程耗时问题,更不说与提名人互动的时间,单是一位编辑读完条目的时间(还没开始敲意见呢),都够另一位用户把本月所有条目全数支持一遍了。而且审议制能否顺畅实行,还是要看有评审能力者——特别是FA、GA主编——的时间与精力。我这类小条目创建者来客串,总是没什么说服力的。--洛普利宁 2022年12月13日 (二) 15:47 (UTC)
各专题人力相差太多。我能想到的可能性就只有我们电子游戏专题自己办评审,选出甲级条目或给予典范条目背书。—— Eric Liu 創造は生命(留言留名学生会 2022年12月14日 (三) 12:38 (UTC)
可能本站从GA评审入手比较合适,FA评审目前先放一边。FA评审的一大问题是人力,但GA检查并不需要专业人士,DYK参与者只要用心也能评审。评议制GA评审再说人少,就真是“不为”而非“不能为”了。另一方面FA检查极其严苛,理论上评审者有更好的想法都要提出来;而我们已经习惯零意见投票制,突然开始严格要求,无论评审人或提名人都难以适应(这次评审估计SilverReaper君都想把我踢出去了)。GA评审在读完全文的前提下“得过且过”,不需要提出海量的意见,也不会花费FAC那样多的时间,我认为比较适合过渡。
找成熟专题试点是很好的方式。像游戏专题、音乐专题地震专题等都有成熟的编写方案和评级队伍,我认为这些专题可以试点“评议制准GA”(aka“乙上级”),将本次的FAC评审模式套用到准GA评审上。一方面有成熟编写方案的加持,新编者和其他领域编者不至于在基本方向上错评;另一方面评级制度活跃,说明领域内有编者把关。此举可以吸收新鲜血液,并将评议制的理念逐渐传播开来。等领域能比较成熟地评议GA后,再考虑FA就是水到渠成了。--洛普利宁 2022年12月14日 (三) 16:50 (UTC)
一脸得意于是就回到我上面说过的方向了嘛。“一部分专题可以先扩权”,有意愿推动“非投票审”的专题,可以先向社群申请这方面的许可,然后当条目出现时,由主审者向FAC报备。搞双轨制。--Temp3600留言2022年12月14日 (三) 19:09 (UTC)
  • 于是又回到中文站人少但条目多的老问题了。我没有什么好意见,想到再说吧。--Temp3600留言2022年12月13日 (二) 17:36 (UTC)
    可能现时并不是全部具建设性的编辑者知道有FA,建议成立评审组,邀请 巡查员及回退员 或 延伸确认编辑者 加入。--唔好阻住我爱国留言2022年12月14日 (三) 02:06 (UTC)
    组织化是可以的,但有不少准备工作。最开首要先建立一个通讯名单,当对应专题的条题被提交时,提示名单上的人可以去看看。--Temp3600留言2022年12月14日 (三) 19:12 (UTC)
    各类工作组,委员会、专题,但反现在的制度都有人,完全没有问题。近期还鼓弄个维基专题:创作物专案互进,转眼“不活跃维基专题”。个人对新开小组没有太大期望,盘活现在的各小组更实际。除非是想要一个XX小组创始人的头衔。--Nostalgiacn留言2022年12月15日 (四) 06:00 (UTC)
    举个例,今天九龙巴士1A线参选FA。以现行的公示制度下,如何让台湾公交编辑者在不留意WP事务的状况下知道九龙巴士1A线正参与FA?--唔好阻住我爱国留言2022年12月15日 (四) 15:24 (UTC)
    台湾公交编辑者应该主动参与台湾专题交通专题,而不是等着他人通告。专题参与人数多了,自然就有人更新参选条目名单(就像这样)。而且不留意WP事务的编辑未必有评审能力,就像不参与游戏专题的编辑者,他们心中的游戏优良条目很可能是游戏道具大全这种负面典型。而且您看看现在的WP:FAC,就算把他们拉过去,他们也只会被{{yesFA}}--~~~~式评审传染。--洛普利宁 2022年12月15日 (四) 15:52 (UTC)
    我得说"自然就有人更新参选条目名单"在目前而言只算是愿望。--Temp3600留言2022年12月16日 (五) 10:00 (UTC)
    那首先把专题搞起来再说。尤其是交通之类的大话题,DYK写公交的、写铁道的编辑大把,不可能说没有人。名单更新由机器人协助都OK,但专题都是死的bot也爱莫能助。虽然评审组也是一个办法,但FA这种依赖领域的评审,到头来还是要靠本领域(或者类似领域)的人把关。--洛普利宁 2022年12月16日 (五) 11:45 (UTC)
    “大部分条目主题都没有活跃的专题组” 的确是阻碍推行评审制的重要原因之一。--Temp3600留言2022年12月16日 (五) 14:13 (UTC)
    参选条目名单现在已经可以由机器人更新了,这倒确实不是问题。--BlackShadowG Slava Ukraini! 2022年12月16日 (五) 14:52 (UTC)
    个人想法,GA评审前条目顶部悬挂横幅2周,征集真实读者的意见,将意见适当纳入改进或评审的讨论环节。技术上尽量降低留言难度(包括快捷与可视化的操作,参考手册及常用模板,开放代理用户留言板等),以及优化横幅观感。--YFdyh000留言2022年12月14日 (三) 17:38 (UTC)
  • 话说回来,@SilverReaper:君自己怎样看?--Temp3600留言2022年12月14日 (三) 19:02 (UTC)
  • 身体好些了。虽然距离完全恢复还要些时间,但我现在能说两句了。我认为评审能否顺利,最大的问题是人们会不会把自己的想法说出来。无论是多小的想法,模糊的感觉还是清晰的问题点,说出来总是要胜过得过且过。有些条目不管是在GA还是在FA,读过去感觉差一些,这个时候应当说出来,而不是当作没看到一样忽视这篇条目的评选而不投票。社群需要时间和努力去完成观念的转变。
  • 我没有遵循英维的惯例,自顾自地开了一个“最终评论期”的东西,这个是我仿照Rust在GitHub上面的Final comment period做的,我无意搞成要挂在公告栏上的公示七天制。
  • 正好最近我在英维接受蔚蓝条目的GA咨询,也获知了一点当地社群的看法。根据英维社群的看法,英维的GA评审实际上无限接近于橡皮图章状态,绝大部分的品质提升在提名条目前的同行评审就已经完成,而且在提名GA前需要征求条目主要贡献者的意见才可提名。GAC非常像把证人逼到当庭认罪后对被告宣判无罪的仪式性流程,所以只需要一个人、一两天即可。以上可供参考。 --MilkyDefer 2022年12月15日 (四) 10:08 (UTC)
    然后是评审标准表格的问题。对不起,我把这事忘了。表格语法我很头疼,经常写不对,而且很费力。我更希望探索一个更好的方案。--MilkyDefer 2022年12月15日 (四) 10:10 (UTC)
    准确来说,与其说是忘了,倒不如说是至少有三次看到那个表格想到要更新,然后看到我自己找到头昏的表格代码,放弃编辑。另外我没有每天都盯着评审专页看。--MilkyDefer 2022年12月15日 (四) 10:20 (UTC)
    (建议使用WP:VE--0xDeadbeef留言2022年12月15日 (四) 11:13 (UTC)
    VE不在维基百科命名空间启用。--MilkyDefer 2022年12月15日 (四) 13:14 (UTC)
    我竟然忘了。。但是可以复制到沙盒之后再粘贴--0xDeadbeef留言2022年12月15日 (四) 13:31 (UTC)
    条目评审前顶部悬挂横幅两周,开放代理用户留言板恕我保留意见。如果这样的话,中华民国总统大概是连GA都上不了了。试想一下开放代理用户留言板后发现人数一边倒地要求把台湾写成中国台湾省,中华民国总统要求改写成台湾地区领导人,总统只能写到李宗仁。--MilkyDefer 2022年12月15日 (四) 10:16 (UTC)
    作参考而不是指标,有编者引用、转述时再讨论。我设想的留言板,放在外部服务中,类似安全投票的附言公布,其他编者可以阅读和取其精华,忽略不合理留言与傀儡行为、可以考虑不存档(定期清除)。“人数一边倒地要求”在存废讨论偶有出现,照常处理即可。GA评审期间也可考虑摘掉或缩减横幅。对于冷门条目,可能不会有多少留言和影响(可以用追踪分类缓解),不影响已有流程。用以缓解评审可能没有兴致与精力仔细阅读条目内容的情况。如果留言点评机制足够方便,常态化更佳,其他百科和知识库系统已有这种反馈机制。--YFdyh000留言2022年12月15日 (四) 10:28 (UTC)
    引入外人这一招不太可靠,除非是引入卓有声誉之士。我敢说,维基百科人的水平还是比平均网民要好上不少。--Temp3600留言2022年12月15日 (四) 15:44 (UTC)
    个人认为GA评选在英维成为“橡皮图章”的情况是审议制实施之后结果,毕竟审议制,形式上无限接近同行评审
    当然“橡皮图章”也可能是部分观点,起码我也留意不少是没有同行评审,直接提交GA,评审员指出了部分需要改善的内容,然后就是审查人没有回应,落选了(1)。也有进行了同行评审,没人回应,提交GA,在评审员和编者合力改善内容,通过的(1)。--Nostalgiacn留言2022年12月15日 (四) 11:21 (UTC)
    基本上,这只能算是少数,多数优良条目与典范条目评选,还是“橡皮图章”多(注:不能否认我个人也挺常充当“橡皮图章”)。—— Eric Liu 創造は生命(留言留名学生会 2022年12月15日 (四) 21:13 (UTC)
    不太认同“橡皮图章”是主流的说法。我去看了当下英维游戏专题参与GA评选的条目,六个条目都没有参与过同行评审,是直接提交GA的。
    优良和典范(特级)是两个标准,正如下文“WP:WIAGA的要求比WP:WIAFA低很多”。“橡皮图章”一说更适用于典范条目,“典范条目之路”({{FAPath}})就是推荐先提交“同行评审”后,再提交FA。--Nostalgiacn留言2022年12月16日 (五) 14:33 (UTC)

其实换个角度看,我们对FA和GA的期望到底是怎样的?比如对于翻译条目,我甚至认为中维心目中的FA(i.e. 社区的最佳条目)就是:

  • 接近WP:WIAFA要求的内容与来源(绝大部分内容enwp编者已经核实,除了个别误译)
  • 接近WP:WIAGA要求的格式(中维没那么多格式手册)
  • 品质高于典型WP:WIACCA条目的行文(大部分内容能看懂,但也有些诘屈聱牙的句子)

这样一方面,那些被指“投水票”的人其实也是认真投的,毕竟社群的期待就这么低。另一方面从荣誉上来讲,同样都是FA,三项都努力逼近WIAFA标准的编者不是很吃亏?(虽然这样的编者大概也不会对FA数量太感兴趣)而FA评选亦非完美条目评选,既然乙级条目的行文可能就已经高于事实标准,评审者有没有必要提出FA级甚至GA级的意见?--洛普利宁 2022年12月15日 (四) 13:33 (UTC)

中维的条目整体质量和标准存在脱节,中维的一些优特是没有格式和指引的,近日魔女之旅剧集列表争议也可见一斑(剧集列表类条目的写法规范)。但是由于翻译自英维高质量内容已经常态化,所以会用英维的标准审视内容。问题可以简化为:中维评选优特是以中维条目整体水平而论,还是直接对标英维的优特水平。--Nostalgiacn留言2022年12月15日 (四) 14:48 (UTC)
一脸得意x2这个就是投票制好处:能够按评审员的水平,动态地调节评审质量,以确保评审本身至少能维持下去。“稳定”、“行政简便”、“荣誉与责任相抵”这些特质在拥有时或许很不起眼,没有了可就得吃苦头。---Temp3600留言2022年12月15日 (四) 16:11 (UTC)
“而审议制则能够提供证据”可以是优势,用得不好就变成实名负责制,大家都害怕背锅。--Temp3600留言2022年12月15日 (四) 16:14 (UTC)
我都认为中维事到如今都没有锅可言了。毕竟眼下只要条目不是特别差,就约等于无意见自动通过(甚至是无视合理意见通过)。所以评审人只要提出建设性意见,无论是否检查出全部问题,都算是在做贡献。(另外有问题就该提,自己不提结果条目通过,只能怪自己喽~)至于争议话题永远达不成共识:反正FA/GA就是个自我参照,永远选不上就永远选不上呗。--洛普利宁 2022年12月15日 (四) 16:30 (UTC)
说到底还是中维对FA/GA的期望,一分货值一分付出。英文FA和GA评审差距很大,可能GA评审30 kB过,FA扩到100 kB被打回三次还过不了。中文FA/GA/DYK就是票数的差距,本质上似乎没有差别。要求低自然不值得多花时间,{{yesFA}}十连发非但不受谴责,反尔有人帮忙说是评审快,就这评审素质哪值得花十分钟总结讨论?每名评审都用一两个小时认真看条目,那审议制的行政时间就算二十分钟也叫零头。--洛普利宁 2022年12月15日 (四) 19:24 (UTC)
要是单纯从改善一分是一分的观点来看,那么投票制也好,什么制都是可行的:中维的主编也不见得完全不理意见。分别在于意见有多重要,或者说,是否规定必须要先完成“一定的评审工作”,才可以当选。要是中维每篇条目都有一名(就够了)评审愿意拿一个小时来看条目,那我当然很支持评审。但如果根本没有这个人呢?延长评审时间是对“等这个人有空前来”有帮助,但如果中维社群根本就没有这方面的人选呢?是否每次都依赖主审将自己的私人时间当作预备队,出现评审缺口就填进去?--Temp3600留言2022年12月16日 (五) 09:57 (UTC)
所以说根本问题还是中维对FA/GA的事实定位。要是按B级条目要求评,一个人一天评十几篇当然没有问题。但问题是既然这样,那FA和GA的意义在哪里?如果供其他编者参考,B级条目真的就够用。所以我们FA/GA就是能上首页刷荣誉的B级条目?
如果真的想执行WP:WIAFA,那其他人的意见必不可少。这种程度的条目主编至少也看过两遍,大问题基本是没有。由于思维惯性、个人知识面和能力,再加上主编看条目已经麻木,一些问题主编自己是看不出来的。这些小问题只有让其他人检查、指点。评审时间本身就应该在在考虑之内:既想不花时间又想达到WIAFA要求,那是不可能的。而且这遍检查完后,编辑之后就会注意同样的问题,并帮助其他编辑发现类似问题,长期来看这对中文维基发展是有利的。如果没有本专业的人选,那近似领域的编辑检查就OK。毕竟我站能力摆在这里,能达到的“最佳品质”就是如此。但之前没有任何实质评审,就凭八个{{tl|yesFA}}--~~~~选出来的条目,我实在不认为代表我们的最佳品质。而且FA完全能少提精选——日维才97篇FA,网上照样一堆人喊“中维垃圾,我看日维都不看中维”;英维也要求每人同时提一个FAC(GAN随意),中维极端时还有一人同时进行10篇候选的。
WP:WIAGA的要求比WP:WIAFA低很多,我甚至认为两者是完全不同的要求。比如这次如果试行GAN,我的意见大概会少4/5。所以我上面一直强调,既然本站没有评议的习惯,那就从GAN开始逐渐培养风气。毕竟GAN评审不用那样耗时。但即便是这样,辐射条目正文1.1万字,仅仅是通读本身都要15分钟,而带着协助改善的思路阅读,时间至少加倍。既然主编愿意花很长的时间来写,而且愿意把条目写好,那我多花一些时间来评审,才是对主编努力的尊重,也是对条目评审流程的尊重。
如果社群对WP:WIAFA和WP:WIAGA不认同,或者认为执行不了,或者认为快餐式评审是最合适的。那坦诚参考WP:WIABCA,实事求是地制定标准会更好。--洛普利宁 2022年12月16日 (五) 11:45 (UTC)
“那么投票制也好,什么制都是可行的”- 投票制当然是可行的,因为中维做投票制都这么长时间了还说不可行不就有点夸大了问题了吗。关于GA的问题:首先我们要考虑一下英维是怎么干的。这我还挺熟悉,因为我之前了一个GA。首先,只有一个人来评审就行,但是必须在每一个要求后打。虽然说只是从多个人每人打一个到一个人打多个,但是区别还是很大的。其中一个区别就是责任的问题。当GA需要重审的时候会把之前让通过的reviewer揪出来批斗。--0xDeadbeef留言2022年12月16日 (五) 14:33 (UTC)
中维的FA重要来源是英维同级条目的翻译本,中维的FAC只是翻译质量审查后追认其FA地位而已。如果需要进行对正文的实质审查,那么的确是应该限制主编的同时提交数量。--Temp3600留言2022年12月16日 (五) 14:25 (UTC)
“找成熟专题试点”我自己当然很支持。如果诸位有此意愿,可以在VPP先行制订专题组申请自行评审的框架方针,后面再自行商议小组内部细则。--Temp3600留言2022年12月16日 (五) 14:31 (UTC)
+1,如果不限制参与者必须加入专题来评审,我觉得提议通过没什么很大的问题--0xDeadbeef留言2022年12月16日 (五) 14:39 (UTC)
我的想法是增设“专题甲级评审”(≈FA的PR)和“专题乙上级评审”(≈GA的PR),大致类似en:Wikipedia:WikiProject Military history/Assessment/A-Class review。有兴趣的专题可以向社区提出申请。社区通过后,在评审步骤上鼓励相关条目先走专题评审,允许专题评审结果在{{Article history}}登记。简单来说,专题接盘PR管改,正式GAN/FAC管审(关系到上首页一类)。至于专题评审过程,所有用户都可以自由参与,专题选一批协调员把关就OK。另外近似领域专题可以考虑合署评审,例如欧洲诸国专题可以在欧洲专题集中review。如果未来多数领域都能普遍运作下去,这种模式也是OK的。--洛普利宁 2022年12月16日 (五) 16:15 (UTC)
我的想法有些不同:专题组有权利自行举办GAC/FAC,在GAC/FAC报备以邀请社群参与后,专题组可按自己的内部程序进行评审,社群则直接认可结果。如果坚持走投票程序或是重审,则继续走投票程序(这个部分日后可以按情况再扩大专题组权限)。PR我觉得没什么人在用,直接从我的想法中略过了。--Temp3600留言2022年12月16日 (五) 16:33 (UTC)
这种作法能实行也OK。就是担心由专题直接裁定结果,会不会把专题变成互煮客栈分栈:比如有人因为条目不通过,把意见转嫁到个别专题,认为专题胡乱评审要求撤权。(毕竟再用投票制还是很容易直接通过,这样专题好像经常做错误决定⋯⋯)--洛普利宁 2022年12月16日 (五) 16:54 (UTC)
主要是还是FA和GA牵扯到利益问题。比如有些用户很重视上首页的问题:例如先评GA,等GA上首页后再评FA,这样条目可以上两次首页。直接由专题评判不通过,这类用户必然是很有意见的。而专题评审和PR只是建议性质,相对能保持专注内容的纯洁性。毕竟如果个别专题而非全站实行,那个别专题就很容易成为出头鸟。希望这只是我过于保守的想法。--洛普利宁 2022年12月16日 (五) 17:07 (UTC)

DYK可否以“你知道在XXX发生过/有过YYY(目标条目)这样一个事物吗?”为格式作问题?

如题,实际情形请见Wikipedia:新条目推荐/候选#2022年俄罗斯入侵乌克兰期间的儿童绑架事件上次讨论我见主要卡关是在格式不齐的问题,上述这个提案是不是既可以保持问题格式,又可以作为直接展现出答案的陈述类型?-某人 2022年12月26日 (一) 01:38 (UTC)

当时的讨论对于直接使用“你知道……吗”也无明显共识,在最后挑选方案时也未被采纳。而且这样的问法会导致展示区出现一条“你知道俄罗斯入侵乌克兰期间上万名乌克兰儿童被俄罗斯军队强迫驱逐到俄罗斯吗?”(有“你知道…吗”包装)而下一条“长洲太平清醮中停办26年的抢包山活动在哪名离岛民政事务专员的任内复办为体育比赛?”(无“你知道…吗”包装),看来也会是按不住因为格式不齐而出现的异议声音。--街燈電箱150號 开箱维修 抄表 检验证明 2022年12月26日 (一) 14:04 (UTC)