维基百科:互助客栈/方针/存档/2023年8月

专人处理IPBE和新账号申请

以下内容为了避免讨论显示过长折叠，任何人仍然可以发言和取消折叠

因为IPBE申请长期积压严重，所以提案由专人处理IPBE和新账号申请的内容。

---

IPBE和新账号申请处理员是一群志愿者，通过邮件列表<待议lists.wikimedia.org>处理因为开放代理而提出的IPBE和新账号申请。

权限包括：

• 添加用户组：IP封禁豁免者（用于处理IPBE申请）
• 不受速率限制影响（用于处理新账号申请）
• 移除自己账号的用户组：IPBE和新账号申请处理员

此用户组的申请条件：

• 有有意愿处理IPBE和新账号申请，了解相关方针指引，能够友善地对待他人
• 编辑数满1000次
• 最近一年内没有受到封禁（不合理封禁除外）
• 在过去三个月内平均每日的编辑次数多于一次

由于该用户组的用户是大陆新用户进入维基百科的一道门槛，所以他们应该被信任能够妥善处理相关事务。此用户组在处理相关内容时会查看到用户的IP信息，授权时应注意用户是否可信。

由于被IP封禁波及的新用户只有在被授予相应权限后才能表现是否为破坏者，所以该用户组不应该因为其授予权限的新用户破坏而剥夺该用户组。

---

上为草案，希望指出有无错误，比如是否因为和封禁申诉共用邮件列表而产生隐私问题。此提案不意图移除管理员的相关权限。--落花有意12138 2023年7月30日 (日) 14:59 (UTC)

目前有Wikipedia:大量账号建立者，是否可以把相关任务授权给该用户组。英文版大量账号建立者主要是用来处理ACC。--GZWDer（留言） 2023年7月30日 (日) 17:52 (UTC)

这样的要求与回退员差不多，而出于隐私考量，已有移除回退员查看私密过滤器的权限的共识。涉及到IP信息，要求显然必须更严格。大量账号建立者目前用途单一且持有者仅有一人，或许可以扩展用途。——暁月凛奈 (留言) 2023年7月30日 (日) 18:05 (UTC)

对于上两条留言的回复请移步下方专门讨论章节留言——落花有意12138 2023年7月31日 (一) 12:07 (UTC)

@暁月凛奈：您的意思是应该提高申请条件吗？我认为这里可以注明需要查看IP信息，然后评选时具体评判用户可信度即可。--落花有意12138 2023年7月31日 (一) 12:28 (UTC)

已加入需要查看IP信息提醒——落花有意12138 2023年8月1日 (二) 13:19 (UTC)

好像以前管理员仍需要做一些检查才能授权，所以需要管理员的一些权限。只是单纯见单就给会不会有问题？或者需要咨询管理员群体确认为什么会出现挤压，或者要考虑逐步恢复管理员的申请来扩充人手，或者督促管理员群体干活？（论又来讨论管理员活跃度的问题）——Sakamotosan路过围观 | 避免做作，免敬 2023年7月31日 (一) 00:57 (UTC)

等一个路过的管理员介绍处理流程--落花有意12138 2023年7月31日 (一) 13:07 (UTC)

需要做的检查就是1.有没有真的被封；2.要求建立的用户名有没有问题；3.封了的IP是不是代理封的。见就给有没有问题？现在基本上就是见就给，但是用户名和“有没有封、是不是代理”还是要看一看。为什么会积压？除了量大，最显著的是易疲劳，即使现在有非常非常好用的懒人工具也是这样。允许更多人来处理会好一点，也就只会好那么一点点。我本人就是处理一次休息几天，连续处理几周得休息几周。就好像当年的模板编辑员一样，几周前我看了一眼，已经没什么模板编辑员在处理编辑请求了。--Tiger（留言） 2023年7月31日 (一) 15:06 (UTC)

那么这个提案用户组应该也需要有活跃度要求，比如六个月处理六十个？或者是是有时间处理申请后火速授权，干到不想干后自己除权。--落花有意12138 2023年8月1日 (二) 13:09 (UTC)

活跃度要求是出于安全考虑而必须存在的，但不应强迫用户处理。——暁月凛奈 (留言) 2023年8月1日 (二) 14:16 (UTC)

@Tigerzeng：因为您比较了解情况，请问是否可能因为和封禁申诉共用邮件列表而产生隐私问题？在处理过程中还需要其他权限吗？--落花有意12138 2023年8月1日 (二) 13:41 (UTC)

除非是安全考虑，否则活跃度要求只能吸引来虚荣的人。说得极端一点，多一个每月处理一个请求的人，相比没有这个人，那每个月不是还多处理掉了一个？如果要非管理员参与这件事，那肯定要和封禁申诉分开。但是被普通IP封禁影响的人（比如很不幸住在LTA家附近的人）仍然有可能走错地方，这些人的IP是真实的IP，肯定不能被管理员之外的人看到，这个部分要考虑周到之后再实施。--Tiger（留言） 2023年8月1日 (二) 14:18 (UTC)

明白二位的意思了，这里不应该有处理的要求。--落花有意12138 2023年8月1日 (二) 14:30 (UTC)

修改处理范围，仅限开放代理。——落花有意12138 2023年8月2日 (三) 13:36 (UTC)

强烈支持加速处理积压。用户组概念不反对。之前TG群中我提过，我是期望表单化申请+自动化处理IPBE的基本申请的，有条件的先授予后审查，再配合防滥用策略，提报和快速处理。需要明确授予和处理流程，是否要涉及IP信息，如何识别傀儡、LTA等行为。“只有在被授予相应权限后才能表现是否为破坏者”存疑，过往授予可能有不少经验上的主观判断。“不应该因为其授予权限的新用户破坏而剥夺该用户组”存疑，那么是否有其他快速机制能建立沟通或强制性审核、禁制。比如类似WP:机器人，要求新用户执行有限次数的试操作，再行评估，试操作期间也可强制如草稿化、WP:AFC；LTA可能“刷编辑”绕过。--YFdyh000（留言） 2023年7月31日 (一) 01:37 (UTC)

认为可以分情况讨论：如果IP只是因为开放代理封的，适用IPBE直接授予和处理员不担责。如果有其他原因，适用给IPBE，并执行一些机制，但是具体机制有待讨论。--落花有意12138 2023年7月31日 (一) 13:38 (UTC)

但目前没有可行机制对该用户组保密IP的同时辨别原因。您是指申请IP无破坏履历或嫌疑，但感觉LTA能做到前者，后者需要靠主观推断，我觉得通通附加机制可能反而好些（不代表拒绝依判断封傀儡）。--YFdyh000（留言） 2023年7月31日 (一) 14:33 (UTC)

都附加机制不合适。第一种情况其实就和正常注册的新用户一样，不应该特殊对待。为了LTA挡住新用户不合适。

我认为这个用户组处理申请应该和现在管理员的方式一样，应该允许查看IP。--落花有意12138 2023年8月1日 (二) 13:37 (UTC)

目前已经挡住了，并且一些维基人期望挡住。我觉得不严厉就可以，像是Tor注册会延迟授予自确。目前我不期望有满足基金会隐私要求且非管理员的该用户组成员，即便有少许，我也觉得变成一个专门且闭门办事的苦差。--YFdyh000（留言） 2023年8月1日 (二) 20:52 (UTC)

已经提出拆分邮件列表案，分割了IPBE和新账号请求和其他封禁申诉。这样应该可以避免IP的隐私问题。

至于附加机制，如果只是延迟自确，我觉得可以接受，但是限制编辑主条目空间之类不同意。——落花有意12138 2023年8月2日 (三) 13:36 (UTC)

m:Steward clerks本地版？--路西法人 2023年7月31日 (一) 15:24 (UTC)

修改Wikipedia:大量账号建立者权限案

以下内容为了避免讨论显示过长折叠，任何人仍然可以发言和取消折叠

两位用户提出可以扩展Wikipedia:大量账号建立者权限，开启分节讨论使结构清晰。

如果要扩展该用户组的权限内容，应该添加的权限是 添加用户组：IP封禁豁免者。该用户组的名称认为不用修改。如果该案通过，上述方针也要一并修改，提出草案如下：

现行条文 ……可以不受速率限制影响地创建账户。用户需要不受注册频率限制创建账户时，可申请大量账号建立权。申请时须附有理由及使用范围（例如在实体聚会、教育专案协助建立账号）。注册账号时需在原因字段提供注册原因，并且不可在24小时内以非申请理由注册超过6个账号。

提议条文 ……可以不受速率限制影响地创建账户和授予IPBE豁免权。用户需要不受注册频率限制创建账户时，可申请大量账号建立权。申请时须附有理由及使用范围（例如在实体聚会、教育专案协助建立账号或者协助处理IPBE）。注册账号时需在原因字段提供注册原因，并且不可在24小时内以非申请理由注册超过6个账号。

现行条文 长期权限与临时权限 无论您申请的是长期权限或是临时权限，皆必须在申请时提出合理的依据。举例来说： 长期权限：若您为教育专案计划主持人等因对外推广而需大量创建账户的使用者，则您可以申请长期权限。 临时权限：若您是为了处理短期计划而需创立大量账户，则在该计划执行期间，您可申请成为账户创建者。

提议条文 长期权限与临时权限 无论您申请的是长期权限或是临时权限，皆必须在申请时提出合理的依据。举例来说： 长期权限：若您为教育专案计划主持人等因对外推广而需大量创建账户的使用者，或者志愿处理IPBE申请，则您可以申请长期权限。 临时权限：若您是为了处理短期计划而需创立大量账户，则在该计划执行期间，您可申请成为账户创建者。

——落花有意12138 2023年7月31日 (一) 12:07 (UTC)

不支持，不符合这个群组的使用目的，这个用户组是给用于组织线下活动时为新人快速新建账户而设立的。这样加权限纯属为胡萝卜找坑填。——Sakamotosan路过围观 | 避免做作，免敬 2023年8月1日 (二) 00:58 (UTC)

感觉大量用户创建者这个用户组的用处都不是很大......相关的志愿处理另设一个用户权限组比较好。--南屿小十233（对话 | 贡献 | 签名） 2023年8月2日 (三) 11:28 (UTC)

(－)反对，显然并非此权限群组的工作，若真有这个需求，也应该另建新的权限群组。--冥王欧西里斯（留言） 2023年8月1日 (二) 09:35 (UTC)

@Cwek、S8321414：两位是同意另一个方案吗？望提出宝贵意见。--落花有意12138 2023年8月1日 (二) 13:55 (UTC)

以目前的状况来说，我比较倾向赞成上面的方案。--冥王欧西里斯（留言） 2023年8月1日 (二) 14:10 (UTC)

别急着提出方案，讨论才过两天。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年8月1日 (二) 14:43 (UTC)

这个让管理员确认，就是管理员授予LIPE时一般需要做什么，里面需要哪些原来在管理员组中的权限，这些权限单独析出来有没风险。如果做不到的话，普通用户也无能为力，管理员的话，或者需要加把劲。（或者有人能设计一套额外的系统，允许用户自行申请，系统挂靠一个授予管理员权限的机器人账户去执行操作；类似en的en:Wikipedia:Unblock Ticket Request System实现申请票单机制，不确定有没直接授权的机制。）——Sakamotosan路过围观 | 避免做作，免敬 2023年8月2日 (三) 00:54 (UTC)

(－)反对，把两件不相关的工作强行融合到一个权限中，十分没有逻辑；即使该提议最终通过，也应当另设用户权限组，而实在不应当简单地将其与现有权限随意结合。--Yiningx（留言|主账户） 2023年8月2日 (三) 01:27 (UTC)

拆分邮件列表

由于现在IPBE和新账号申请和封禁申诉共用同一个邮件列表，提案用户组不应该能查看封禁申诉，所以提出拆分邮件列表。因为开放代理提出的IPBE和新账号申请在新的邮件列表，封禁申诉（包括非因开放代理的IPBE）在原有的邮件列表。

提出新邮件列表名称草案：

1. wikipedia-zh-ipbe
2. wikipedia-zh-openproxy
3. ipbe-zh
4. openproxy-zh

以上。——落花有意12138 2023年8月2日 (三) 13:36 (UTC)

所以说您在急什么（ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年8月2日 (三) 14:01 (UTC)

我不急，真的 :-)--落花有意12138 2023年8月2日 (三) 14:24 (UTC)

建立新用户组提案

IPBE授予者及新账号建立员是一群志愿者，通过邮件列表<待议lists.wikimedia.org>处理因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过开放代理编辑维基百科的用户提出的IPBE和新账号申请。

权限包括：

• 添加用户组：IP封禁豁免者（用于处理IPBE申请）
• 不受速率限制影响（用于处理新账号申请）
• 移除自己账号的用户组：IPBE授予者及新账号建立员

此用户组只能处理因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过开放代理编辑维基百科的用户的申请，不能处理其他原因的IPBE申请。

此用户组不能为自己建立具有IPBE权限的新账号，或授予IPBE给自己的其他账号。

建议IPBE授予者及新账号建立员在授予IPBE权限后一天内关注被授予者的编辑记录。

申请条件：

• 有意愿处理IPBE和新账号申请，了解相关方针指引，能够友善地对待他人
• 编辑数满1000次
• 最近一年内没有受到封禁（不合理封禁除外）
• 在过去三个月内平均每日的编辑次数多于一次
• 已成为巡查员、回退员或傀儡调查助理三个月以上

由于授予IPBE权限时应较为谨慎，所以他们应该具有一定反破坏或反傀儡经验，能被信任能够妥善处理相关事务。此用户组在处理相关内容时会查看到用户的IP信息，授权时应注意用户是否可信。

权限的丧失：

当IPBE授予者及新账号建立员有滥用权限的嫌疑（例如未收到申请而授予IPBE权限，使用权限帮助滥用傀儡）时，任何用户均可以前往Wikipedia:申请解除权限举报，由一名未参与举报的管理员核查后决定是否移除IPBE授予者及新账号建立员的权限。遇紧急情况时管理员可以暂时取消IPBE授予者及新账号建立员的权限，但必须同时立即上报至Wikipedia:申请解除权限，让其他管理员进行复核。

由于被IP封禁波及的新用户只有在被授予相应权限后才能表现是否为破坏者，所以该用户组不应该因为其授予权限的新用户破坏而剥夺该用户组。

当IPBE授予者及新账号建立员自身已因滥用傀儡而被封禁时，管理员应同时立即除权。

另外，当超过六个月没有任何编辑活动时，权限将会被移除。

根据原版调整了一下条文。桐生ここ★[讨论] 2023年8月10日 (四) 14:49 (UTC)

IPBE授予跟大量账号建立不应放在一起，应该单独授予。--冥王欧西里斯（留言） 2023年8月10日 (四) 23:34 (UTC)

@S8321414：有IP封禁的人不能注册账号，如果不授予大量账户创建权限，处理员会处理更少（不知具体是多少）--落花有意12138 2023年8月11日 (五) 10:48 (UTC)

“具有一定反破坏或反傀儡经验”：为什么处理权限申请需要反破坏经验？处理两申请只能看到邮件，而反破坏是看内容，有很大区别。

“只能处理因政府网络限制……”：我认为无法分辨是否是此情况，尤其此用户组没有查核的权限。也可以要求申请人证明其居住地？具体方法想不出来。--落花有意12138 2023年8月11日 (五) 10:39 (UTC)

反破坏经验是希望IPBE授予者在事后能关注被授予者的编辑记录是否为破坏，或是否为傀儡。至于只能处理因政府网络限制，是申请者说明自己是因政府网络限制并且查询封禁ID确实因为代理而被封禁就可以授予。如果申请者说因为我的IP上有破坏被封IP，或者查询封禁ID发现是因为破坏而封IP，或者申请者说我不想被CU所以需要申请，就需要由管理员判断，IPBE授予者不能处理。桐生ここ★[讨论] 2023年8月13日 (日) 12:38 (UTC)

(？)疑问 好奇为什么必须成为巡查员等权限拥有者，是为了确保有一定社群处理经验？——顺颂时祺 ZhaoFJx^{（论•编）} 2023年8月12日 (六) 02:12 (UTC)

是，也是为了确保IPBE授予者有反破坏或反傀儡经验，因为IPBE在一定程度上可以干扰CU，在其他语言维基甚至可能需要先CU才能授予IPBE权限。IPBE授予者不因非故意授予IPBE给破坏者而取消授予者权限，但最好能够在授予之后短期内关注被授予者编辑记录，并且有能力发现问题及时挽回。桐生ここ★[讨论] 2023年8月13日 (日) 12:51 (UTC)

授权要求非常的宽松不是件好事，毕竟这玩意儿可以弄出一堆可以绕过在你维被封的IP的账号。--SunAfterRain 2023年8月13日 (日) 13:38 (UTC)

我是期望宽进（直接授权）、严出（有限编辑）的，但预防绕过和滥用可能很难做到。或许能配合滥用过滤器的功能来预防一部分。--YFdyh000（留言） 2023年8月13日 (日) 20:38 (UTC)

@YFdyh000：如果说要配合防滥用过滤器直接授权，某种程度上自动广泛授权（即魔琴所说的斜坡计划）可能还比较好一点吧，--SunAfterRain 2023年8月18日 (五) 10:27 (UTC)

不确定指哪部分，我不赞成那个计划的反审查和身份验证步骤。--YFdyh000（留言） 2023年8月18日 (五) 17:26 (UTC)

很担忧这种权限的设立。以英文维基百科为例，如果使用代理编辑，一般需要先联系CU人员才能申请到IPBE。中维本身已弱化经该要求，而现在又要继续降低门槛。假若该权限设立，那么某个破坏者只需注册多个邮箱账号，中维的所有封禁方法对此破坏者便基本失效。毕竟过滤器能拦截的破坏只是破坏中很少的一部分。且CU的有效性也会因此受到影响。--Yiningx（留言|主账户） 2023年8月14日 (一) 14:06 (UTC)

@Yichen Ding：现在如果管理员勤快一点，也会出现您所说的问题，处理缓慢使得这种问题不太明显。如果担心破坏账户处理不过来，可以等待既存的用户都核查差不多了再给新的；或者限制申请必须等待几日才能处理。--落花有意12138 2023年8月15日 (二) 07:55 (UTC)

然而原本处理IPBE申请的人员可能只有3名（非真实情况，下同）勤快（赋权标准较低）的管理员和5名会仔细对用户申请进行询问的管理员，即使这几名“勤快”的管理员速度再快，处理申请也有上限，即使赋权后发现是破坏者傀儡，管理员自己也能尽快处理，总体不会产生太大影响；而“IPBE处理员”们上任后，突然多出了30名“只能赋权，不能除权、封禁的，勤快的管理员”。如果限制申请通过速度，那又和现在没有什么区别——两者都要等差不多一周才会通过。此外，就该草案本身而言，“申请时会看到IP信息”是否意味着此权限组要签NDA？而“有滥用权限的嫌疑”更是无从查证——回退员仅因“可能向破坏者泄露过滤器信息”便被除掉相关权限；现在居然有这样一个权限，可以直接帮助破坏者绕过封禁，难道拥有这样权限的用户真的一定比回退员更值得信任吗？--Yining Chen（留言|贡献） 2023年8月15日 (二) 14:46 (UTC)

所以如果用规则+机器人限制新IPBE账号的权限和封禁，是否可以呢。无法完全避免LTA冒充新人，但目前规则似乎同样依赖管理员的主观识别+低效率批准。还可以机器人提醒处理人员批准后有多少涉及破坏，以调准批准率。--YFdyh000（留言） 2023年8月15日 (二) 14:56 (UTC)

直接给IPBE授予者一个义务，就是授予权限7天内要关注被授予者的编辑记录，如果发现新用户破坏可以取消自己授予出的IPBE权限(不得取消别人授予的IPBE权限)，并需立即在WP:申请解除权限请管理员复查，并提报到VIP请社群判断是否为LTA；如果判断自己授予的新用户可能是傀儡，可以取消自己授予出的IPBE权限(不得取消别人授予的IPBE权限)，并提报到傀儡调查，等傀儡调查出结果后由管理员重新授予IPBE权限或封禁。--桐生ここ★[讨论] 2023年8月16日 (三) 14:10 (UTC)

另外，我个人认为IPBE处理员需要比回退员更值得信任，因此申请要求应该比回退员高，甚至需要进行WP:RFA，至于为什么要求IPBE处理员担任回退员、巡查员、调查助理三个月也有这个原因，需要IPBE处理员已经有反破坏、傀儡的相关权限，没有拿这些权限去做坏事，在社群中已经有一定信誉。比方说现任的傀儡调查助理，我相信他们会正确使用IPBE处理员的权限，不会故意将IPBE授予给LTA。--桐生ここ★[讨论] 2023年8月16日 (三) 14:30 (UTC)

同意相关提案，毕竟有时候我连自己都也不相信，有必要做满三个月。--Hoben7599—论 | 支持立场新闻 2023年8月18日 (五) 06:04 (UTC)

1.认为上面桐生ここ提出的方案可行。

提议条文 在合理时段内，IPBE申请处理员应该监督其授予权限者，确保其做出建设性编辑；如做出不当编辑，授予者有责处理。如达到封禁标准，授予者暂时移除IP封禁豁免权，转交管理员处理，管理员处理后重新授予IP封禁豁免权。

那么其权限应该加入移除用户组IP封禁豁免者。

2.上面已经提到过根据是否是“因开放代理封禁”而分离邮件列表，处理人应该只能看到因为开放代理封禁的申请，认为此不属于用户隐私。

3.认为两者的职责不同，信任也是不同的，不可相对比较。认为破坏者更可能换IP而不是申请IPBE。

@Yining Chen——落花有意12138 2023年8月17日 (四) 09:04 (UTC)

首先，foundation:Legal:Confidentiality_agreement_for_nonpublic_information中定义的“Nonpublic personal data”中包括IP信息。我不太了解这个条款是否涵盖了该权限所涉及的权限内容。如果该权限需要候选人签NDA，那么应该更加谨慎地考虑该权限与用户查核员权限的关系。建议就此事咨询WMF法务部门。另外，“授予者只能除权自己授权的IPBE权限，而不能除别人的权限”是从技术上限制还是从方针上限制？毕竟如果恶意将一名拥有IPBE权限的用户（现在有3064人）除权，那么就相当于间接封禁了该用户（而且只能通过unblock-zh寻求解封，因为被除权人无法通过站内渠道申诉），这样大的权限甚至能和过滤器维护员相比。该用什么措施去尽可能防止这种情况发生呢？有人可能说回退员的权限也很大，能批量回退编辑，但该权限一方面有编辑频率过滤器限制，另一方面也无法将其它用户封禁，总的破坏要比滥用“IPBE权限维护员”权限小得多。最后的( π )题外话：我个人认为SPI Clerk在可以预见的，相当长的一段时间内人数应该都不会再增加（除非现有成员隐退）。--Yining Chen（留言|贡献） 2023年8月17日 (四) 10:24 (UTC)

随着匿名编辑的IP将匿名化等推进，我倾向IPBE授予应该尽量少介入和依赖完整IP地址做判断，用实际编辑等做判断。如果不想等系统做开发修改，我强烈建议用管理员权限的机器人实现IPBE授予、解除乃至规则化临时封禁，获权用户提报然后机器人检测和执行（可限制频次、条件），以及可以临时封禁被提报或过滤器检出的明显破坏以等候复查；错误封禁的日志记录可做删除。--YFdyh000（留言） 2023年8月17日 (四) 15:37 (UTC)

反对8月17日的新建议条文，一来难以执行，二来不应有权移除权限。--路西法人 2023年8月19日 (六) 04:22 (UTC)

如果IPBE及新帐号处理员需要WP:RFA，您是否同意有权移除权限。--桐生ここ★[讨论] 2023年8月19日 (六) 10:22 (UTC)

借用维护员讨论中的一句话：“我相信他们能做好这些，所以我不怀疑他们会做那些。”--Yiningx（留言|主账户） 2023年8月19日 (六) 12:33 (UTC)

如果需要类似RFA的程序，那就不需要此权，直接选limited administrator好了。如果他们能创建大量账号，即使有“在合理时段内”才需要的监视限制，但处理多的人就很难监视所有获授权者的编辑是否恰当。除权等于封锁用户，故反对将除权的权限授予此组。--路西法人 2023年8月20日 (日) 04:17 (UTC)

反对8月17日新建议的条文，原因是IP处理者及管理员在授予权限时，所能得到资讯极少，我们甚至无法透过这名使用者的编辑情况下去判断。

再来即便是授予后管理员及IP处理员也没那么多时间再去一一查看授予权限后的编辑情况，时间没那么多，不符合实际现况难以执行。

如果说要保证IPBE不被滥用那么最好的情况是尽快恢复本站的Checkuser，让本地的CU去定期随机的查核。--~~Sid~~ 2023年8月20日 (日) 07:54 (UTC)

edit.~~Sid~~ 2023年8月20日 (日) 08:02 (UTC)

咱认为这种所谓的连坐机制是非常奇怪的，管管授予权限/协助创建帐号后，新用户怎么做，甚至被发现是LTA被封了都不是管管的错——一封邮件里的信息量少得可怜，要是能从一个想要创建的用户名看出这是什么LTA也是神了；到了这里提议的IPBE处理员，为什么就应该监督其授予权限者，确保其做出建设性编辑了？回到这个用户组的创建上，管管相比于“IPBE处理员”到底多了什么，让别人认为可以放心地交给她们处理账户请求/IPBE权限申请呢？从权限的角度来说，IPBE跟别的权限差别很大，一般要是授予，比如巡查员这种权限，那管管会扫视近来的编辑记录和新页面巡查的完成度，甚至会问一些问题；而IPBE完全不需要你对这个申请用户进行什么审查（特指一个编辑数量极少甚至刚刚创建的用户），这也意味着，咱个人认为，IPBE处理员不需要那种“识人”的能力。要是说一个社群投票就可以解决对其是否信任的问题，我们完全可以搞社群投票，类似于BAG和CU clerk那种形式啊。如果你认为“申请时会看到IP信息”所以要签NDA，那目前处理unblock-zh的管管不是也有没签署的啊；你可以理解成管管由于受到社群选举产生所以受到高度信任，那我们这个组的产生采取类似的机制，做到选出来的人也可以高度信任，是不是就可以认为没有这方面的顾虑了。目前对于IPBE的处理已经很宽松了，并不能推出“设立IPBE处理员会造成许可十分宽松”这种结论，设立IPBE处理员并不意味着“继续降低门槛”，某个破坏者只需注册多个邮箱账号这种事情在没有IPBE处理员的时候也没有很好的办法。IP Editing的推进跟本案咱感觉没有太大的关系。 Stang^★ 2023年8月19日 (六) 18:06 (UTC)

Stang老师这段话说服我了，所以我现在支持这个IP处理员的提案，本人也非常愿意协助帮忙授予受到IP封锁影响的新用户IPBE。--~~Sid~~ 2023年8月20日 (日) 07:44 (UTC)

“我们完全可以搞社群投票”，正如上方所说，如果搞一个社群都信任的，类似RFA的投票，我们为什么不直接选出一个管理员？对某名用户的信任可以划分为不同等级吗？“我信任这名用户可以很好地处理IPBE权限，但我不相信他能很好地处理巡查员权限申请”，是这样吗？--Yiningx（留言|主账户） 2023年8月27日 (日) 11:02 (UTC)

对某名用户的信任可以划分为不同等级吗？是。为什么有行政员、管理员和界面管理员？他们都是需要RFA才能担任的。而且所谓类似RFA的投票条件肯定需要比管理员的投票宽松。--桐生ここ★[讨论] 2023年8月27日 (日) 15:39 (UTC)

新用户组提案 版本2

IPBE授予者及新账号建立员是一群志愿者，通过邮件列表<待议lists.wikimedia.org>处理因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过开放代理编辑维基百科的用户提出的IPBE和新账号申请。

权限包括：

• 添加用户组：IP封禁豁免者（用于处理IPBE申请）
• 不受速率限制影响（用于处理新账号申请）
• 移除自己账号的用户组：IPBE授予者及新账号建立员

此用户组只能处理称因政府网络限制（如身在中国大陆受防火长城限制）而仅能通过开放代理编辑维基百科的用户的申请，不能处理其他原因的IPBE申请。

此用户组不能为自己建立具有IPBE权限的新账号，或授予IPBE给自己的其他账号。

申请条件：

• 有意愿处理IPBE和新账号申请，了解相关方针指引，能够友善地对待他人
• 编辑数满1000次
• 最近一年内没有受到封禁（不合理封禁除外）
• 在过去三个月内平均每日的编辑次数多于一次
• 已成为巡查员、回退员或傀儡调查助理三个月以上

由于授予IPBE权限时应较为谨慎，所以他们应该能被社群信任妥善处理相关事务。此用户组在处理相关内容时会查看到用户的IP信息，授权时应注意用户是否可信。

权限的丧失： 当IPBE授予者及新账号建立员有滥用权限的嫌疑（例如未收到申请而授予IPBE权限、使用权限帮助滥用傀儡）时，任何用户均可以前往Wikipedia:申请解除权限举报，由一名未参与举报的管理员核查后决定是否移除IPBE授予者及新账号建立员的权限。遇紧急情况时管理员可以暂时取消IPBE授予者及新账号建立员的权限，但必须同时立即上报至Wikipedia:申请解除权限，让其他管理员进行复核。

由于被IP封禁波及的新用户只有在被授予相应权限后才能表现是否为破坏者，所以该用户组不应该因为其授予权限的新用户破坏而剥夺该用户组。

当IPBE授予者及新账号建立员自身已因滥用傀儡而被封禁时，管理员应同时立即除权。

另外，当超过六个月没有任何编辑活动时，权限将会被移除。

根据Stang的回复做出了调整，不再要求“识人”，而是要求被社群信任。桐生ここ★[讨论] 2023年8月23日 (三) 07:12 (UTC)

辛苦了，可是话说要怎么才能知道“未收到申请而授予IPBE权限”呢？普通用户应该是看不见IPBE邮件列表罢。还是说会定期进行审查？——顺颂时祺 ZhaoFJx^{（论•编）} 2023年8月24日 (四) 00:40 (UTC)

不允许“未收到申请而授予IPBE权限”的意义是：

即使是现实认识的朋友因翻墙需要IPBE，也需要先发邮件申请才能授予权限，不能直接就授予权限让人无法查证。

至于如何知道，授予IPBE时需要进行备案，而且管理员和其他IPBE处理者可以看到邮件列表，如果发现违规可以举报。--桐生ここ★[讨论] 2023年8月24日 (四) 09:22 (UTC)

前面tiger提出需要考虑走错的可能，即邮件列表受到非开放代理的ip封禁的豁免权请求。此非ipbeg应当处理，所以应该由有权限查看真实IP的用户剔除，比如管管，或可以要求用户在标题或者邮件开头按照一个固定的机器可读模式提供信息，自动鉴别。——正在思考的落花有意12138 2023年8月26日 (六) 14:28 (UTC)

上方积极推进提案的用户似乎只有桐生ここ和落花有意12138，而明确表达支持意见的则很难找到（Stang？）。提案者对上方的几条反对意见不加以回应，令本人感觉十分遗憾。为何“草案调整”及相关讨论只是选择性地考虑支持者的意见呢？难道提案人希望绕过（“无视”？）反对意见，“强行”推进提案通过吗？--Yiningx（留言|主账户） 2023年8月27日 (日) 10:59 (UTC)

我应该有回应您，比如“IPBE处理员们上任后，突然多出了30名只能赋权，不能除权、封禁的，勤快的管理员”，提出了IPBE处理员有义务监督新用户而且可以除权的想法，不过阁下没有对此表示看法，而路西法人等人反对IPBE处理员可以除权，stang反对监督义务。新的提案是参考了多方的意见，不是只参考了stang的回应，也不是强行推进提案通过，而根据意见持续修改提案，而且上面讨论也有其他人表示支持提案。--桐生ここ★[讨论] 2023年8月27日 (日) 15:29 (UTC)

投票制度

丝糖提出投票，此开分节讨论。

首先需要讨论是否需要投票。落认同其可作为社群信任的证明，但是可能会出现参与人少和通过率低的情况。

提出如下细节问题供讨论：

1. 最低参与人数的设置：太高可能没人投票而落选，太低不能反应共识
2. 投票用时：太短可能不能反应共识，太长可能使提名人丧失热情。我建议题名即开始投票，周期14日，同时设置一个雪球机制。
3. 是否使用安全投票

这里提供一个草案，内容可以讨论：

---

权限的获取：

具投票权的用户可在Wikipedia:IPBE授予者及新账号建立员/申请提名满足上述条件的用户为IPBE授予者及新账号建立员。

提名发出后

• 管理员应该核对提名人和被提名人的资格，不合资格的关闭（其他用户也可关闭），合格的留言说明
• 用户可讨论，具投票权的用户可投票

投票进行三日后，管理员可用雪球法则关闭明显不受社群信任投票；进行7日后，如同意票数大于等于总票数的四分之三，管理员可以关闭投票并授权；进行14日后投票截止，管理员点票，符合以下条件的授权：

1. 票数大于8票
2. 同意票多于二分之一
3. 弃权票少于三分之一

---

以上——不甚活跃的落花有意12138 2023年8月26日 (六) 14:28 (UTC)

DYK字数约定

看有编者在Wikipedia:互助客栈/方针#追废已上首页的DYK的做法就现时而言是否合理？中提到“DYK这一套是从英维搬过来的”，想问下是否可以参照更新一下英维字数约定。英维约定为en:Wikipedia:Did_you_know#Eligibility_criteria：Articles must have a minimum of 1,500 characters of prose (ignoring infoboxes, categories, references, lists, and tables etc.) 。目前中文维基约定为“不少于3000字节（注：1个汉字 = 3个字节）”。但有些没几句话的条目插入信息框和参考文献后，很容易过线，用了信息框注释<!-- -->和web.archive.org后能增加更多字节。（以下举例条目无关dyk）

参考文献占字符举例：例如我用奥本海默_(电影)里第一个参考文献测试下，单个ref就能占用585字节；

信息框占字符举例：例如HTV-X1条目，一共没几句话，字节数却高达11,175字节，基本都是| declared = <!--when the operator/agency officially ended the mission-->这种无用信息框注解在占用字节。 --桃花影落飞神剑（留言） 2023年7月20日 (四) 20:30 (UTC)

这只是基本的推荐资格吧。要登上DYK也得看条目品质如何。——WMLO※议程表 2023年7月20日 (四) 22:31 (UTC)

像最近7月的几个通过DYK的条目，如米素尔·保利臣 （正文8句话）、尼克拉斯·施密特（正文8句话），按英维不算信息框、表格和参考文献的标准就可能被卡掉。--桃花影落飞神剑（留言） 2023年7月21日 (五) 00:07 (UTC)

或许可以要求所有正文加起来有一400汉字。--落花有意12138 2023年7月21日 (五) 00:37 (UTC)

我觉得可以严格一些，同时要求不少于3000字节（非小作品）与正文不少于1500字节，不然如果有人写了正文刚刚好1500字节的条目交上来DYK，但条目被挂了小作品模板也有些尴尬。Sanmosa _{In vain} 2023年7月21日 (五) 00:53 (UTC)

现有的“不少于3000字节（注：1个汉字 = 3个字节）”的门槛自2007年至今十几年都没有改过，而2007年时并不流行infobox、cite系列等等模板。就以2007年的这个约7000字节的DYK与2023年的这个约9000字节的DYK来比较，前者可读的正文长度竟比后者明显多几倍，也许可以说DYK的长度门槛要求今天可能已经追不上通胀。至于要求正文不少于1500字节，有没有技术方案可以让人清晰计算正文长度？--街燈電箱150號 开箱维修 抄表 检验证明 2023年7月21日 (五) 03:01 (UTC)

JS表示：.replace( ... ).replace( ... ).replace( ... ).replace( ... )...XDDD--路西法人 2023年7月21日 (五) 03:20 (UTC)

现在的DC规则有“有效长度”的设定（自DC18起），但我不记得当时有没有弄计算有效长度的小工具了，如果有的话，基于那个小工具改动一下应该能解决问题。@Temp3600。Sanmosa _{In vain} 2023年7月21日 (五) 04:12 (UTC)

• DC的有效长度是手算的，但有小工具可以协助去除模版等技术性字节。另同意增加正文长度要求。--Temp3600（留言） 2023年7月23日 (日) 02:46 (UTC)

(※)注意，DC的有效长度还是有算进ref跟infobox的字节数，不能直接沿用。(＋)支持以正文长度作为要求，像是不久前结束的2023年非洲月，要求便是“符合DYK标准且正文达300汉字”，可以考虑沿用。--巴波（留言） 2023年7月23日 (日) 06:50 (UTC)

300汉字（即900字节，连1/3都没有）未免要求太低了。现有的3000字节在2007年已经实行，当年每个条目在不流行infobox、cite的情况下正文长度大多占超过2/3，那么应可预期3000字节的原意是希望正文不应该少于2000字节。现在提出正文至少要1500字节已算是非常宽松了。--街燈電箱150號 开箱维修 抄表 检验证明 2023年7月25日 (二) 03:49 (UTC)

至少300汉字是一个社群已形成共识、可以实施的低标，再往上调高就要再继续讨论形成共识。--巴波（留言） 2023年8月5日 (六) 10:14 (UTC)

300汉字顶多只是社群对于非洲月长度的共识，但不认为这也代表社群对于DYK长度的共识也是这么低（像是阿萨伊塔只有400汉字也没有成DYK）。坦白说，我想一个DYK的字数水准，不应该连一个初中毕业生也不如吧（以港澳教育标准来看）。--街燈電箱150號 开箱维修 抄表 检验证明 2023年8月18日 (五) 13:27 (UTC)

英维有一个检查条目是否符合DYK标准的小工具，我之前搬过来了，User:Interaccoonale/DYKcheck.js，但是它计算字数可能是按照空格算一个单词来计算的，明显需要改一改才能用于中维。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月25日 (二) 14:51 (UTC)

我搞不定了。有没有人知道偏好设置里面那个字数计算小工具是怎么实现的？--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 02:36 (UTC)

好像是js对于基本多文种之外的字符支持有问题，我放弃。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 06:23 (UTC)

那个数文本的可以看脚本实现。好像是算CJK的话将Unicode的CJK范围的字替换成“.”，其他替换空白，而算字节的话按照UTF-8的范围分组替换为对应字节长数的“.”，然后都是统计“.”的数量就是了。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月26日 (三) 07:26 (UTC)

我看过了，那个小工具只统计了基本多文种平面的字符，参照堆栈溢出StackOverflow的这个帖子来看，应当是js对于辅助平面的支持有问题。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 07:53 (UTC)

@Cwek：所以技术上能做得到吗？毕竟这种计正文字节的工具要是真能弄出来，日后也不止DYK能用到。Sanmosa _{In vain} 2023年7月26日 (三) 08:51 (UTC)

看上面，他说这个工具在js实现上存在一些技术问题，不过大部分字符在Unicode的BMP的话，大概没问题？——Sakamotosan路过围观 | 避免做作，免敬 2023年7月26日 (三) 09:16 (UTC)

我想了一下，认为应当可以忽略扩展区字符。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 10:55 (UTC)

@Interaccoonale：这样的话，可能就有劳你制作一下那个具体的小工具了。Sanmosa _{In vain} 2023年7月26日 (三) 11:11 (UTC)

字数的部分应该已经改好了，但是它有个问题是，它计算的长度是“散文长度”（prose size），也就是说用 *、# 这样的方式生成的列表不被计算在正文字数内，然而MOS:列表目前在中维不是共识。如果社群认为列表应当被计入正文字数内的话，这小工具还得再改改。（另外这个小工具还有检测条目创建时间以及扩充程度是否达到DYK标准的功能，那些我稍后按照中维标准改完。）--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 12:24 (UTC)

另外还有表格也不被计算在内，例如现在在首页DYK上的埃玛·基米莱宁按照这种计算方式可能被认为不达标。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 12:44 (UTC)

副知@Cwek：。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 13:01 (UTC)

@Interaccoonale：一些个人意见：（1）虽然Wikipedia:格式手册/列表#列表的形式目前在中维不是共识，但社群一般默认以*、#点列的都是列表，所以就不内嵌于表格内的点列列表而言，只计算“散文长度”是正确的，因此这不完全是bug，你看一下金昌柱 (古生物和古人类学家)的论文列表就知道我在说什么了。（2）表格也不被计算在内确实是个bug，但像“正文不少于1500字节”的要求本来也不能完全依赖小工具，如果真有人写了列表的话，这可能需要算正文字节数的人就表格内容手动算字数了（不过如果那个列表条目单计“散文长度”也有1500字节的话，表格算不算好像也没太大关系？），所以如果可以的话建议把这个bug修理一下（而且内嵌于表格内的点列列表也要算正文长度）。Sanmosa _{In vain} 2023年7月26日 (三) 13:20 (UTC)

据我所知也有很多人会在以 *、# 这样的方式生成的列表中撰写“散文性”内容（姑且就用这个词吧），例如欧亚红松鼠#文化表现及欧乌鸫#亚种，这类内容不计入正文长度私以为不甚合理。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 13:32 (UTC)

@Interaccoonale：那你还是想办法让以*、#点列的列表的内容有办法算进去吧，但这或许也意味着DYK的正文长度最终只能手算，而完全不能依赖小工具了。要不你想办法提供不同模式的算法，让用户选择以*、#点列的列表要不要算正文长度？Sanmosa _{In vain} 2023年7月26日 (三) 13:44 (UTC)

听起来可以，不需要用户手动选择模式，直接给出两种结果即可。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月26日 (三) 13:47 (UTC)

也可，但内嵌于表格内的点列列表应该在两种算法下均计入正文长度。Sanmosa _{In vain} 2023年7月26日 (三) 22:19 (UTC)

为什么？能给一个例子吗？--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月27日 (四) 00:18 (UTC)

我想不起具体例子了，但内嵌于表格内的点列列表的作用应该是在格中再分项，这时这些分项显然地也属于“正文”的一部分。或许最终计算的方式应该有三种，分别是完全不计算点列列表、仅计算内嵌于表格内的点列列表，以及计算所有点列列表。另外有一点值得留意的是，一些表格并不是直接用wikitable语法来建立的，比如美国那些县级行政区列表中的表格都是引用含wikitable语法的模板来建立的。Sanmosa _{In vain} 2023年7月27日 (四) 08:38 (UTC)

我注意到参见和外部链接以及部分参考资料用的也是点列式列表，技术上无法把它们和正文中的列表区分开。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月30日 (日) 02:19 (UTC)

应当考虑提高字数（字节）要求，惟同时应设立过渡期俾编者适应。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年7月26日 (三) 04:06 (UTC)

我觉得具体的处理方式可以是“同时要求不少于3000字节（非小作品）与正文不少于1500字节”的新规定于2024年1月1日才正式实行，但在社群通过此提案至2024年1月1日期间将预备实施新规定的公告放在DYK页里，这应该能满足“过渡期”的需求。Sanmosa _{In vain} 2023年7月26日 (三) 08:48 (UTC)

(！)意见：如果是这样做，那不是增加撰写的难易度了吗？（针对不是“从其他语言维基百科翻译过来”的条目）--Sinsyuan FA工作室 2023年7月26日 (三) 14:12 (UTC)

其实infobox、cite于后期的大流行其实无形中降低了撰写的难易度，现在只是要追回旧日应有难易度罢了。--街燈電箱150號 开箱维修 抄表 检验证明 2023年7月26日 (三) 14:41 (UTC)

我不认可Cdip150的看法。我个人的意见是这样做确有增加撰写难度的可能性，但增加的幅度不至于大到使DYK出现优特评选化的情形。这至少能让用户谨慎选题，而不会为写而写，写出一些用大量非正文内容堆砌条目长度的条目。Sanmosa _{In vain} 2023年7月27日 (四) 08:32 (UTC)

我想了解，是否可以统计近月通过DYK条目的正文字数，像是中位数为几字、正文低于1500字的条目占多少百分比？有这些数据应该有助于讨论出合适的字数门槛，也避免大幅影响DYK。--巴波（留言） 2023年8月5日 (六) 10:14 (UTC)

(＋)赞成。----Cat on Mars 2023年8月6日 (日) 01:54 (UTC)

在社群通过新指引之前的这段时间，该如何对待字数明显不足的条目呢？比如正在8月5日评选中的这一条英超夏季系列赛，总字节4209字节，正文4句话。--桃花影落飞神剑（留言） 2023年8月6日 (日) 01:48 (UTC)

我觉得倒也不用特别针对表格进行狙击，但真的这么极端的情况的条目我觉得也不会有多少人会关注，一般而言只要真的符合基本要求，真过了几个也不用过分担心。Sanmosa _{In vain} 2023年8月6日 (日) 04:47 (UTC)

(！)意见：个人觉得假设英维要求1500字元的限制，我认为本维可以简单采用4500字节(以1汉字=3字节)的限制来规定DYK标准，个人觉得假设有人觉得候选条目过了这新DYK标准还不够有资格，自然会提出反对并指出条目过短，或是不投票(使条目净支持不到4票)而使提名条目被否决，不用大费周章设太多规定使得新编者做了条目不敢提DYK，降低一部分用户的编辑意愿。谨此表露自己陋见，敬请见谅。--${\ce {Be + He->B+ +e- +H- +e+}}$，这是β衰变和正电子发射，请无视其他能量释放。 2023年8月21日 (一) 07:46 (UTC)

@Cwek、Sanmosa、Cdip150：DYKCheck脚本已经按照本地DYK规则适配完毕，在自己的common.js中加入importScript('User:Interaccoonale/DYKcheck.js');即可使用，推荐在新旧Vector和Timeless下使用。目前考虑到列表和表格一般不是散文内容，因而暂未将其计入。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年7月30日 (日) 02:44 (UTC)

感觉可以，但你的小工具似乎是计字数？这里讨论的正文要求都是以字节计，这样的话相当于要重新考量一个以字数计的正文要求（可能是500字？）。Sanmosa _{In vain} 2023年8月4日 (五) 15:34 (UTC)

这样。那么我看一下给它增加按照字节数计算的功能。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年8月8日 (二) 09:03 (UTC)

已经加入按照字节计算的功能。--——🦝英特浣熊耐尔_{（留言・贡献）} 2023年8月10日 (四) 16:41 (UTC)

如果要对正文字数做出限制，列表类条目撰写的难易度可能有明显增加。列表的正文只有导言，那就代表对于一般条目而言针对全文的字数要求，在列表条目则是在导言就需要达到。举例而言，中华人民共和国已撤销地级市列表这篇条目，列表内容很全面，是篇FL，但导言只有186字，无论如何都不可能达到正文字数要求。故(＆)建议将列表类条目排除在正文字数要求之外。--BlackShadowG Slava Ukraini! 2023年8月9日 (三) 13:33 (UTC)

我个人倾向列表条目的列表／表格内容也计入正文，但现时的小工具无法做到这点，因此可行做法有两个，一个是对列表条目的引言的字数／字节数要求下修并订为对一般条目的字数／字节数要求的三分之一，另一个是要求计算列表条目的字数／字节数时须人手计算（或至少人手计算列表／表格部分）。Sanmosa _{In vain} 2023年8月10日 (四) 00:19 (UTC)

对列表条目的引言的字数／字节数要求下修并订为对一般条目的字数／字节数要求的三分之一，据我所知，不少用户并不擅长给列表写一个完善的导言。此外，对于列表项很少的列表，要求写一个长度达标的导言可能有些强人所难。

要求计算列表条目的字数／字节数时须人手计算（或至少人手计算列表／表格部分），对于行政区划列表、物种列表等，即使把列表的内容算进字数／字节数，也不会有很多……--BlackShadowG Slava Ukraini! 2023年8月12日 (六) 03:11 (UTC)

@BlackShadowG：（1）现时小小作品的定义是50字以内，假如对一般条目的正文字数要求是500字，那列表条目的引言的字数／字节数要求就会是166⅔字，也就是3又⅓个小小作品的长度。完不完善不是重点，但“要求写一个长度达标的导言可能有些强人所难”这点我认为你有必要具体说明一下，并举出实例，否则我感觉我无法理解你有这个说法的原因。（2）这点我倒是可以理解，我要看看其他人是怎么想的。Sanmosa _{In vain} 2023年8月13日 (日) 09:49 (UTC)

我指的是“对于列表项很少的列表，要求写一个长度达标的导言可能有些强人所难”，我曾经在FLC看到过只有两个列表项的条目，但实在没有耐心再重新把那篇条目找出来了，对于此类列表项很少的条目，导言长度相应的就会变短，亦可能难以达到长度要求。--BlackShadowG Slava Ukraini! 2023年8月13日 (日) 14:19 (UTC)

我曾经自己送过至少两个只有两个列表项的条目到FLC，它们的引言长度都长于166⅔字。Sanmosa _{In vain} 2023年8月14日 (一) 23:20 (UTC)

有一说一，这种列表本身就不太合格⋯⋯ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年8月15日 (二) 06:54 (UTC)

再不然我把要求下修为一般条目的字数／字节数要求的四分之一（即125字、2.5个小小作品的长度）也可。Sanmosa _{In vain} 2023年8月15日 (二) 14:26 (UTC)

那么像是上面的英超夏季系列赛（列表外的正文有130汉字）如此单薄的内容也还是有资格了……（虽然这个实质上是非列表，但不排除会有人用这种写法、然后将引言仿照欧洲冠军联赛决赛列表的形式稍为改一下就变成了列表），那我会觉得意义很小了。我跟Ericliu1912的意见类似，“列表项很少的列表”本来就不太适合DYK（在“列表项很少”的情况下仍能写出长度很可观的引文则另当别论），这里又没人叫大家要选一个先天不足而又无法靠后天努力的取材来参选，遑论强人所难。敝人还是认为列表条目的引言内容加列表内容总和最少也要500汉字才合适。--街燈電箱150號 开箱维修 抄表 检验证明 2023年8月18日 (五) 13:27 (UTC)

@BlackShadowG。@Cdip150：可以以定义的方式限制“引言”为wiki系统下的section 0，section 0外的文字一概不视为引言。说明一下，我之前送到过FLC的那两个只有两个列表项的条目一个引言278字，另一个引言246字，还有一个因历史断代的缘故而只可能有四个列表项的FL引言553字，不过好一部分的引言内容跟其他10个同类列表的引言内容重合（那11个列表都是我写的，所以这样做并不存在版权问题）。考虑到DYK本身意在鼓励用户多写条目，我不太建议对用户过分严苛。Sanmosa _{віки-віків} 2023年8月18日 (五) 15:34 (UTC)

那样的话像是化学元素发现年表这种内容丰富的列表反而会失去资格了（序言只有90汉字），反而制造了另类的严苛。而且这种限制不见得有效——只要把全部的一般文段都不分章，全部合起来放在第0章已经能绕得过。其实列表条目内的一般文字内容与列表内容共享这500汉字的下限，我觉得已经是最平衡的做法。--街燈電箱150號 开箱维修 抄表 检验证明 2023年8月23日 (三) 16:30 (UTC)

我更倾向于列表只要满足其中一个要求（即全文正文含表格内文字至少500字或列表引言至少166⅔字）即可，而非直接以列表引言至少166⅔字的要求取代正文至少500字的要求在列表的适用性。另外，我不认为有人会如此闲地特意钻这些规则的漏洞，这种情况下保持假定善意显得非常必要。Sanmosa _{віки-віків} 2023年8月28日 (一) 23:56 (UTC)

• 引言要100字以上对于某些领域的某些主题可能有困难，例如这个六维正七胞体、四维正十一胞体引言只有五十几字，也很难再多了，不希望还得硬挤废话去堆叠引言。这个条目我认为是符合DYK标准的，其也确实上过首页。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年8月29日 (二) 15:48 (UTC)

  --( ✓ )同意，在某些领域(尤其是科学方面)中的条目引言文字在常见情况下不大可能很多，个人觉得与其设下一个更为强硬且复杂的DYK初步审查标准，使原本可能可以参与维基百科使用者审核的条目会直接褫夺资格，不如加强社群审核条目的力量，适当在不合资格的条目投予反对票或是直接不投支持票使条目无法获选，因为个人相信大部人在投DYK票时候，应该会把条目先读过一遍再投票，谨此表露自己个人陋见，敬请见谅。--${\ce {Be + He->B+ +e- +H- +e+}}$，这是β衰变和正电子发射，请无视其他能量释放。 2023年8月31日 (四) 13:31 (UTC)