置顶公告:【置顶】关于临时开启评论区所有功能的公告(2022.10.22) | 【置顶】关于本站Widget恢复使用的公告
  • 你好~!欢迎来到萌娘百科镜像站!如需查看或编辑,请联系本站管理员注册账号。
  • 本镜像站和其他萌娘百科的镜像站无关,请注意分别。

萌娘百科 talk:提案/已通过提案/关于进一步规范讨论空间的提案(2022.01.16)

贴贴♀百科,万娘皆可贴的百科全书!转载请标注来源页面的网页链接,并声明引自贴贴百科。内容不可商用。
跳到导航 跳到搜索

序言

当前提案包含对萌娘百科:讨论区管理方针的修订完善(全文替换)与对萌娘百科:提案中页面格式的进一步规范(修订)。高三的维护人员对不起了,我之后还有一个提案,得先进行这个了( —— ほしみ 2021年12月27日 (一) 15:59 (CST)

正文

讨论区管理方针

本页面是针对萌娘百科的讨论区而制定的管理方针,针对讨论页面的论述请参见萌娘百科:讨论页面,评论区管理政策请参见萌娘百科:评论区管理方针中的相关内容。

萌娘百科的讨论区是萌娘百科的一部分,可分为公共讨论页(包含Talk、萌娘百科 talk、Template talk等)与用户讨论页(User talk)。

  1. 用户应参照本方针进行发言或讨论;
  2. 管理员巡查姬应当处理不符合方针的内容。

内容

  1. 涉及到以下内容的讨论应当被维护人员删除并警告:
    1. 危害国家及社区安全的敏感信息;
    2. 淫秽色情内容;
    3. 无关广告类内容;
    4. 欺诈链接/钓鱼木马/捐款购买链接等内容;
    5. 其他由维护人员讨论后主观认定的特殊情形;
    • 一般情况下,维护人员应使用{{InvalidSpeech}}标记删除发言。
  2. 讨论页上的多项内容原则上需大体符合时间顺序,包括:
    1. 同一讨论页上的多个话题;
    2. 对同一条发言的多条回复;
    3. 同一话题下的多条直接非回复性发言。
  3. 原则上不允许用户修改或删除他人或自己的讨论内容,以下情况除外:
    1. 使用删除线划去自己的发言或投票;
    2. 修复自己近期发言的排版或错别字;
    3. 在您发言后且无他人参与当前讨论串前的一小段时间内继续编辑您的发言以稍作改进,但不得改变初次发言中的原意;
    4. 对特定讨论页的格式进行排版优化;
    5. 为未签名用户的讨论补标发言者名称与时间戳;
    6. 移除假造其他用户发言的签名并补标发言者名称与时间戳;
    7. 对导致界面排版错误的发言进行必要修复,以维护讨论区秩序。但不应改变发言者表述内容;
    8. 对讨论串进行合理的剪切移动。且应同时使用{{movedto}}与{{movedfrom}}进行标记;
    9. 其它政策文件中许可的行为(如萌娘百科:提案允许提案发起人修订提案);
    10. 行政员特别许可的页面维护行为(如Cewbot[更多]讨论页贡献上传历史封禁及历史被删贡献移动日志巡查日志用户权限及日志用户查核失效锚点的维护需要增删讨论页内容)[改 1]
    11. 其它由维护人员讨论后主观认定的特殊情况。
  4. 用户在讨论页的发言应当文明友善。
  5. 用户不应当在讨论页加入其它名字空间专用的分类。
  6. 用户在讨论页发言后应当签名,签名须符合签名之规定[改 2]
  7. 无需创建无有效讨论内容的讨论页以下讨论页允许进行存废处理[改 3]
    1. 符合萌娘百科:方针#应当被立即删除的内容之规定或本节第一条提到的情形;
    2. 空白讨论页面;
    3. 无链入的讨论页重定向(如移动残留等);
    4. 机器人创建的、使用完毕的维护用页面(如Cewbot[更多]讨论页贡献上传历史封禁及历史被删贡献移动日志巡查日志用户权限及日志用户查核失效锚点的维护需要增删讨论页内容);
    5. 新用户将评论误发送至页面讨论页。
    • 此处的新用户指发言前未获得自动确认用户用户组的编辑者。若其创建了新讨论页,维护人员可选择删除页面;若仅添加了新发言,则应使用{{InvalidSpeech}}进行标记。
公共讨论页

在上述规范的前提下,

  1. 涉及到以下内容的讨论应当使用{{hide}}等模板隐藏(原则上应当由维护人员操作):
    1. 完全乱码类内容;
    2. 人身攻击/侮辱/刻意冒犯他人的内容;
    3. 无关于当前讨论串的内容;
    4. 错误发送至讨论页的评论;
    5. 其他降低讨论质量的内容。
  2. 萌娘百科讨论:讨论版的子页面,特别允许:
    1. 非维护人员使用{{RemovedMAR}}移除标记为「无人回复」的{{MarkAsResolved}};
    2. 维护人员删改或是使用{{RemovedMAR}}移除{{MarkAsResolved}};
    3. 维护人员直接删除用户重复发送的整个讨论串。
  3. 编辑战原则上应当在公共讨论页解决;
  4. 在符合萌娘百科政策的前提下:
    • 任何用户不得阻止他人参与公共讨论;
    • 公共讨论页的讨论结果具有一定的效力,亦可提出反对讨论串。
用户讨论页

在内容遵守萌娘百科整体规范及上述规范的前提下,

  1. 用户在自己的讨论页内:
    1. 允许自行适当装饰、排版自己的讨论页,但不允许自动播放音视频;
    2. 在特殊情况下应当使用{{help}}以请求帮助。但不应滥用以扰乱秩序;
    3. 允许存档或删除用户留下的整个讨论串,视为已读该留言;
      • 当存档或删除维护人员留下的警告留言或模板时,视作已读该警告(注:模板:忍耐是有限的无法被用户自行删除);
    4. 除必要的页面保护外,不应进行将页面用作沙盒等行为导致他人无法正常讨论;
    5. 当出现页面过长或过度装饰等影响页面加载的情形,导致他人查阅、讨论受阻时,用户应当存档或删除过期讨论串、减少不必要的装饰;
      • 此条规定在有多名维护人员认定或其他用户于操作申请版提出申请时启动;
      • 若认定情形属实,维护人员应当首先提醒用户处理,用户一周内无响应则应协助处理;
    6. 用户讨论页不应重定向至用户子页面之讨论页。
  2. 用户可以在他人讨论页内:
    1. 留下欢迎信息模板:
      • 用户可以为自己发放或在留言需要新建他人讨论页时发放此类模板;
      • 除前一条所述情形外,仅有维护人员可以为有编辑记录的用户发放此类模板;
      • 发放此类模板时应通过模板参数或是签名标明发放者,且须符合#签名一节之1、2条之规定;
      • 除既有的{{welcome}}、{{欢迎}}外,不再允许新增欢迎信息模板;
      • 禁止向他人发放自定义欢迎模板或展开模板源代码以规避此条限制。
    2. 进行正常交流对话;
    3. 发送维基友爱
  3. 维护人员可以在用户讨论页进行警告:
    1. 留置警告提示时,应含有“疑似维护人员留下警告”标签(维护人员留言内容或摘要包含“警告”2字,则会自动触发滥用过滤器进行标签)。
    2. 可放置或移除自己放置的{{忍耐是有限的}}模板。

  • 若出现违反上述规范的行为,维护人员应立即处理并提醒或警告。若警告无效,维护人员可视情形按用户封禁政策之规定进行处理。
  • 特别地,若用户对其他用户进行人身攻击,拒绝停止相应行为或无悔改意愿,封禁时长可按方针规定的一年内第二次、第三次进行次数累计、时长累加。

签名

用户在讨论区的签名(即“~~~~”),须遵守以下规定:

  1. 在发言签名;
    • 若在页面中相互不连续的多个位置均新增了内容,应多次签名。[增 1]
  2. 能够正确地区别出您和其他用户:
    1. 包含指向您的用户页、用户讨论页和(或)贡献页的内部链接(以上三个中的一个或多个);
    2. 不允许伪造他人签名,不允许添加除已公示的分身账户之外的前一条所述之链接;
    3. 不允许包含不实的用户组信息(含冒充维护人员)。
  3. 包含讨论区规定使用的时间戳:
    1. 内容一节第3条中的可修改情况与欢迎信息模板的特别规定外,任何发言必须添加时间戳;
    2. 不允许使用{{unsigned}}代替签名;
    3. 在需要机器人维护的特定讨论区,有符合格式要求的签名须符合以下格式要求[改 4](含源代码及实际显示):
      • 参考格式:【四位年份】年【月份,无前导零】月【日期,无前导零】日 (【星期数】) 【小时,前导零】:【分钟,前导零】 (【时区,仅接受CSTJSTUTCUTC+[1-12]UTC-[1-12]】)
      • 样例:2021年1月14日 (四) 05:14 (CST)
      • 正则表达式(不符合此正则表达式的不被认为是可接受的时间戳):
        /[1-9]\d{3}年(?:0?[1-9]|1[012])月(?:0?[1-9]|[12]\d|3[01])日 *(?:[((](?:[金木水火土日月]|(?:星期)?[一二三四五六日])[))])? *(?:[01]\d|2[0-3]):(?:[0-5]\d)(?::[0-5]\d)? *[((]([CJ]ST|UTC(?:[+-](?:[1-9]|1[012]))?)[))]/ ,参见 regexr 上的演示
  4. 萌娘百科:方针#破坏行为一节之规定外,还须符合以下内容规范:
    1. 不应存在未使用替换引用(subst:)而直接嵌入的任何页面;
    2. 不应包含模块、templatestyles或Widget;
    3. 除不带参数且非高开销的系统变量外,不应包含任何魔术字;[增 2]
    4. 外部链接仅允许萌娘百科及其姊妹站点的链接。
  5. 须符合以下排版要求:
    1. 实际显示不含有闪烁或动态的样式、图像;
    2. 实际显示的颜色不应过于刺眼、难以识别或设置过低的不透明度[改 5]。其中,链接的颜色不应与默认文本颜色相同或近似链接应与默认文本有视觉上的区分[改 5]
    3. 实际显示不含有影响排版或难以辨认的,过大或过小的字体;
    4. 源代码不应多于1000字节,且实际显示长度不影响界面排版;
    5. 源代码不包含可能影响排版的代码(如实际显示不应具有跨行之功能不含有主动跨行功能的代码[改 5])。;
    6. 源代码不包含语法错误的代码。
  6. 允许签名中使用符合规范的图像:
    1. 允许使用不多于2个位于萌娘百科及其姊妹站点的图像(通常以<img>标签形式引用img.moegirl.org.cn开头的外链);
    2. 图像高度或宽度须小于等于50px,且不影响页面排版;
    3. 除图像外的媒体文件禁止使用;
  7. 未出现多名维护人员(3人或以上)认定明显不合适的其他情况。

  • 若出现违反上述规范的签名,维护人员应立即提醒或警告。若提醒后该用户仍不予理睬、我行我素,维护人员可视情形按萌娘百科:方针#用户封禁政策之规定进行处理。
  • 用户违反签名规范时,维护人员应移除该签名中的不当部分,或将其签名整体替换为{{unsigned}}或标准签名(即“[[User:用户名|用户名]]([[User_talk:用户名|讨论]])20XX年X月XX日 (〇) XX:XX (CST)”格式)。

存档

讨论版存档

为防止萌娘百科讨论:讨论版的子页面过长,导致页面加载、提交编辑等行为过于缓慢,以下为讨论版存档机制:

  • 机器人存档机制:
    • 讨论串已结束讨论(被标记{{MarkAsResolved}}后指定时间)或10日无新发言,则将讨论串进行剪贴存档。
    • 在原讨论页(萌娘百科讨论:讨论版的子页面)仅保留讨论串标题,并悬挂{{Saved}}模板进行标记。
    • 萌娘百科讨论:讨论版的子页面中,保留标题、内容存档的讨论串,其标题将于每月1日删除。
  • 存档页面命名:
  • 其它存档机制:
    • 群组信息版的存档由维护人员手动进行。
    • 注销账户申请版的存档由管理员手动进行。
    • 在特定情况下,维护人员亦可对讨论版进行手动存档。
用户讨论页存档

当用户选择对用户讨论页上的讨论串进行存档时:

  • 不允许将讨论串存至本站用户讨论名字空间(User talk)以外的位置。
  • 须采用子页面存档固定链接存档的方式进行存档。
  • 允许用户自行申请删除子页面存档。[增 3]

其它

  1. 在特定情况下,管理员可使用滥用过滤器以帮助讨论区的管理。
  2. 如若管理员巡查姬多次在讨论区进行违规管理操作,视作对萌娘百科的破坏,按照方针中的相关内容进行处理。
  3. 免责声明:参见萌娘百科:免责声明

提案

  1. 废除Talk:提案页面(改为至方针页面的重定向),将Talk:提案#过往政策讨论页面这一节移入萌娘百科:提案末尾(参考萌娘百科:快速提案);
  2. 修订正式提案一节:
    • 提案页面发起位置修订为「萌娘百科_talk:提案/讨论中提案/XXXX」,下同;
  3. 修订提案格式一节:
    • 「如果出现了提案页面超限的情况,则将“提案正文”一节移入子页面(萌娘百科_talk:提案/讨论中提案/XXXX/提案正文)」变更为「若提案发起时正文字节数超过3w字节,提案发起人可选择将“提案正文”一节移入对应的Project页面(萌娘百科:提案/讨论中提案/XXXX)」;
  4. 修订提案存档一节:
    • 「每份提案存档都要在页面名后面加上投票结束日期(日月年格式)」后插入「若提案未进入投票阶段,则添加提案终止日期」;
    • 移动所有提案存档至【萌娘百科_talk】名字空间。

修订注释区

  1. 依照#关于签名放置位置的限制之意见添加。
  2. #对签名规定中表述的调整中的意见总结,新增对魔术字的明确限制。
  3. 补充存档删除相关规则。

  1. 移动相关内容至存废政策。
  2. 移动至签名一节。
  3. 修改这一小节为存废处理政策,并从公共讨论页移动至内容一节。
  4. 同步现有讨论区管理方针签名一节中的内容。
  5. 5.0 5.1 5.2 #对签名规定中表述的调整进行调整。


讨论区

关于签名放置位置的限制

建议增加对讨论区签名放置位置的限制:

  1. 签名必须放置在自身新增内容的末尾,一般不应换行。
  2. 新增内容为块状元素时允许换行。
  3. 当在一次编辑中,在页面中相互不连续的多个位置均新增了内容,应插入多个签名,放置位置限制同其他规定。
  4. 签名应具有上下文辨识度,下一点的这类位置不应放置签名。
  5. --サンムル讨论) 2021年12月27日 (一) 16:25 (CST)
第1点的话我认为不宜过严限制,除了块状元素外,如果发言包含多行,那签名前换行也很可能是有利于观感的。“一般不”这样模糊点我觉得也不是不可以,别限太死就行。
第3点强烈支持,见过不止一次了……
第4点没看太懂,但我觉得不是太大的问题,可以不管。
——C8H17OH讨论) 2021年12月27日 (一) 22:28 (CST)
我觉得或许可以限制签名时多次换行的行为,比如实际显示为【内容】+【空一行及以上】+【签名】,见过几次;另外除了3可能不需要限的太死吧大概 —— ほしみ 2021年12月28日 (二) 01:17 (CST)
第2點"新增內容為塊狀元素時允許換行",當前這邊的機器人或許能解析,但是不保證其他的工具也都能正常運行,故恐怕有疑慮。 --Kanashimi讨论) 2021年12月31日 (五) 06:50 (CST)
第2点是考虑排版问题吗?如果是我感觉改为内容末尾为块状元素时可以换行更好,这个角度考虑是签名紧接着块就容易影响。
第3点对由本人操作导致的不连续很好,但由非本人操作导致的讨论内容不连续(比如不同的人在用户A不同的讨论段回复,导致用户A每段之间不连续了)该如何处理签名?(毕竟目前好像也只有查阅该讨论串该级缩进末尾签名是谁的办法了......)——6116G讨论) 2022年1月1日 (六) 16:57 (CST)
由于切割其他人的发言是非常不礼貌的行为,这种情况下应当恢复发言的原貌,并提醒对发言进行切割的用户。——From 引梦者浊华(讨论) 2022年1月1日 (六) 19:42 (CST)
额......比如萌娘百科讨论:2021年方针修订专案/最终决定权的讨论#最终决定权的同意率与事后质询这一章的两段这种情况,是否也算切割?——6116G讨论) 2022年1月1日 (六) 23:27 (CST)
对,您应该多次签名。不然很难找到谁说了什么。—— ほしみ 2022年1月2日 (日) 00:08 (CST)
好的,我以后将考虑得更周到,在多段连续讨论可能引起将来他人回复切割的地方也会签名。——6116G讨论) 2022年1月2日 (日) 20:35 (CST)

U:YOONHA~1.PAR关于时间戳的意见

  1. 时间戳整体是否允许个性化? (如: 将时间戳同时封装进签名中和前面的用户名等信息一同使用字体等样式, 使用时键入 ~~~)
  2. 「星期数」 为中文语境下才会有的说法 (在星期日这种情形下这甚至也不是数字), 可能需要替换为更为合适的叙述; 考虑到机器人现在支持了JSTUTC时区, 那么可否容许类似于月火水木金土日以及Mon Tue Wed Thu Fri Sat Sun的星期序列存在?
  3. 承上一点, 归根结底星期这一参数是否为机器人维护之必要参数? 若无必要可否自行去除? (参考: 英文维基百科讨论中通常不加星期几)
  4. 全角括号符合中文版式, 时间戳反而使用半角符号会使得排版不伦不类, 除非所有讨论当中统一使用半角符号, 包括特制的句号顿号等, 故可否通融在时间戳中使用中文的全角括号

_USER:YOONHA~1.PAR(暂定签名, 留言页。 )2021年12月27日 (一) 10:06 (UTC)

不行,可能影响多个扩展对签名的解析,包括影响计划中的讨论扩展对签名的解析。另,由于讨论扩展的需求,可能需要对签名进行更严格的限制,例如在默认签名中增加用户贡献页面的链接等。具体以运维方升级mw版本/安装扩展时的附加需要为准。—— ほしみ 2021年12月27日 (一) 18:19 (CST)
本人认为现存之几点均不存在破坏机器人维护操作的意图 (仅年月日、 时间以及时区为机器人维护所需要的参数), 对这些扩展做出合理的更动并无技术难点。 还请允许本人暂且反对此案。 _USER:YOONHA~1.PAR (暂定签名, 留言) 2021年12月27日 (一) 10:43 (UTC)
1、可,时间戳可被包含在任何元素内,只要其源代码符合格式且不被其他内容截断即可;
2、这个表述我也找不到更合适的;已允许月火水木金土日,但考虑到萌百是中文社区,不支持英文版本;
3、可去除;
4、时间符号根据国家标准GB/T 7408-2005《数据元和交换格式 信息交换 日期和时间表示法》规定应使用半角的连字符、冒号和斜线,括号是可以使用全角括号的。
可接受的时间戳的正则表达式:/[1-9]\d{3}年(?:0?[1-9]|1[012])月(?:0?[1-9]|[12]\d|3[01])日 *(?:[((](?:[金木水火土日月]|(?:星期)?[一二三四五六日])[))])? *(?:[01]\d|2[0-3]):(?:[0-5]\d)(?::[0-5]\d)? *[((]([CJ]ST|UTC(?:[+-](?:[1-9]|1[012]))?)[))]/ ,参见 regexr 上的演示。——From AnnAngela the Bureaucrat (Talk) 2021年12月29日 (三) 12:02 (CST)
十分感谢,辛苦了。_USER:YOONHA~1.PAR(留言)2021年12月29日(三)07:42:34(UTC)
這邊現在採用的是 /([12]\d{3})年([[01]?\d)月([0-3]?\d)日 \(([日一二三四五六])\)( [0-2]?\d:[0-6]?\d)(?: \(([A-Z]{3})\))?/gseealso --Kanashimi讨论) 2021年12月31日 (五) 06:32 (CST)
那么理论上应该需要取交集了... 问问@AnnAngela的意见。—— ほしみ 2021年12月31日 (五) 11:22 (CST)
建议@Kanashimi整合一下上面那个正则,可以考虑加个?以及非捕获组。——From AnnAngela the Bureaucrat (Talk) 2021年12月31日 (五) 12:44 (CST)
這邊採用的是萌娘百科自動簽名(4個或5個波浪符號)使用的日期和時間格式。像是"金木水火土日月"、秒或jst似乎沒被使用? --Kanashimi讨论) 2021年12月31日 (五) 17:18 (CST)
“金木水火土日月”感觉应该考虑的是萌百是中文社区,很少会有日本时区的人的样子。没有jst好像确实是个问题。秒的话有没有其实都无所谓了,毕竟人类也感知不到。--木织元讨论) 2022年1月16日 (日) 06:05 (CST)

关于提案正文的位置

首先把提案从Talk移动到Project_talk空间我一把子(+)支持。然后关于提案正文的位置,我很早前就提出过把提案正文放到非讨论页的建议,有便于检查是否只有发起人修改、便于参与者查阅提案正文变更情况、便于投票期间添加保护等种种好处,同时还能保证对提案正文的修改免受讨论页方针的规制(#内容第3.9条的举例)和Cewbot的烦扰。我个人激进的想法甚至是要求所有提案正文都放在Project页的;现在至少给了可以放Project页的机会,但我在想能不能把字数要求也去掉,给提案发起人更大的选择权。——C8H17OH讨论) 2021年12月27日 (一) 22:23 (CST)

主要是考虑到有些不太长的提案,如果再单独开页面,反而对点进来阅读的人不太友好,不过我(+)支持增加一些允许单开页面的情形,但是暂时没有啥想法( —— ほしみ 2021年12月28日 (二) 01:15 (CST)

关于讨论页方针部分条文逻辑的非实质性意见

#内容第3.10条和#公共讨论页第3.3条算是近期实践中发现的新问题,写入方针我觉得(+)是好的,不过我觉得条文顺序可以调整一下,可以把“失效锚点的维护需要增删讨论页内容”和“新用户将评论误发送至页面讨论页”都各自算作单独的一条“可以删除讨论内容的特殊情况”放到#内容第3条里或者在#公共讨论页里单开一条,因为前者已经是方针明文许可的了、不需要作为“行政员特别许可的情况”,而后者在“无需创建无有效讨论内容的讨论页”(“什么时候应该删讨论页”)里又多规定了只移除内容的说明。总之都是条文逻辑上的问题,不算是实质性意见。另外,{{InvalidSpeech}}需要写个文档( ——C8H17OH讨论) 2021年12月27日 (一) 22:23 (CST)

应该改好了。{{InvalidSpeech}}已经降低过保护等级了,那文档就交给你了( —— ほしみ 2021年12月29日 (三) 11:55 (CST)

对签名规定中表述的调整

#签名一节:

  1. “除萌娘百科:方针#破坏行为一节之规定外,还须符合以下内容规范”中需不需要增加对于解析器函数、系统变量、状态开关的限制?(如果限制了,U:Bhsd的签名将会不符合规定)
  2. 对于“实际显示的颜色不应过于刺眼、难以识别或设置过低的不透明度。其中,链接的颜色不应与默认文本颜色相同或近似。”
    • “过低的不透明度”已被“难以识别”包含,无需此句;
    • “链接的颜色不应与默认文本颜色相同或近似”这句可以改为“链接应与默认文本有视觉上的区分”,因为颜色不是能提示链接的唯一方法。
  3. “显示不应具有跨行之功能”的“跨行”不妥。正常的文本在到达边界时也会跨行。“主动换行”或许更好。

 あめろ 讨论 2021年12月29日 (三) 13:46 (CST)

关于第一条,我建议是不允许状态开关、可变的系统变量、包含运算与逻辑判断的解析器函数等。—— ほしみ 2021年12月29日 (三) 15:30 (CST)
(-)反对 这条发言为什么我没有收到提示?我觉得只需要禁止状态开关就行了,因为会改变整体页面的属性。其他魔术字未见限制的必要性。——移动版用户 Bhsd 2021年12月30日 (四) 22:29 (CST)
另外关于链接的提示,我认为需要加上不能仅通过:hover、:active等伪类样式,而是必须默认样式就与默认文本形成区分。——移动版用户 Bhsd 2021年12月30日 (四) 22:36 (CST)
抱歉!我以为加上用户页链接和签名就可以给对方提醒了,看来下次得好好用{{Reply to}}了。签名的4.2 “不应包含模块、templatestyles或Widget”可以限制伪类的使用。 あめろ 讨论 2021年12月30日 (四) 22:44 (CST)
有道理,是我傻了。——移动版用户 Bhsd 2021年12月30日 (四) 22:51 (CST)
用户页链接和签名确实可以给用户提醒吧?我在下一行试一下。
@Bhsd 我倒是认为没计算完的解析器函数也不好,比如不少人直接用模板替换展开,展开后出现冗余的if、ifeq、switch等内容也应该移除。
链接提示我认为可以改为“链接应与默认文本有视觉上的直接区分”,具体情况具体判断就好。—— ほしみ 2021年12月30日 (四) 22:48 (CST)
考虑到讨论内容可能事后会被移动,有些解析器函数可能替换与不替换的效果会不同——移动版用户 Bhsd 2021年12月30日 (四) 22:51 (CST)
可以给个例子吗?我认为至少用switch达成每个页面不同签名等效果应该在签名被解析前完成,而不是签名发出来之后的源代码仍包含此类解析器函数。—— ほしみ 2021年12月30日 (四) 22:55 (CST)
先说可变的系统变量吧,PAGENAME、NAMESPACENUMBER等在发生讨论内容移动时可能含义就会发生改变。而如果if、switch之类的分支用到了这些系统变量,那展开与否也会不同。——移动版用户 Bhsd 2021年12月30日 (四) 23:05 (CST)
如果是签名提交之后仍保有if、switch之类达成每个NAMESPACENUMBER有不同签名效果这种情况,我还是觉得不该有,不论签名是否被移动。这是签名而不是讨论内容啊( —— ほしみ 2021年12月30日 (四) 23:12 (CST)
那就限制解析器函数和带参数的系统变量,但不限制不带参数的系统变量吧。如果仅限制部分解析器函数,感觉除非列出一个限制表,否则会含糊不清。如果可以接受的话,我也尝试修改下签名。——移动版用户 Bhsd 2021年12月30日 (四) 23:22 (CST)
我觉得应该没问题吧,解析器函数这一块或许可以采用白名单的方式(?。另附加限制一个高开销的系统变量。—— ほしみ 2021年12月30日 (四) 23:30 (CST)
我记得不带参数的时候系统变量没有高开销的吧?居然还真有!CASCADINGSOURCES。——移动版用户 Bhsd 2021年12月30日 (四) 23:40 (CST)
雖然沒全面測試過,但採用這些 magic words可能造成工具失常,恐須謹慎。尤其若未來想引入維基百科回覆工具的話。 --Kanashimi讨论) 2021年12月31日 (五) 07:00 (CST)
根据MW:Help:DiscussionTools/Why can't I reply to this comment?,只要用户链接和时间戳符合要求即可。——移动版用户 Bhsd 2021年12月31日 (五) 23:36 (CST)
這邊曾遇過用戶連結與日期之後還接一大串、接了兩個相異用戶連結與日期的,有時不太好判斷。 --Kanashimi讨论) 2021年12月31日 (五) 23:46 (CST)
这已经和魔术字毫无关系了吧……——移动版用户 Bhsd 2021年12月31日 (五) 23:58 (CST)
您說的對。建議第三項主動換行改成換行字元,並且添加上已使用者連結與日期做結,這樣或許會更方便判斷。 --Kanashimi讨论) 2022年1月1日 (六) 05:05 (CST)

换成“字元”的话,<div></div>算不算換行字元呢? あめろ 讨论 2022年1月1日 (六) 13:23 (CST)

這邊可以處理這個例子,但是不保證其他的工具也都正常。我想大多數工具都是檢查最後一行最後一個使用者連結與日期。 --Kanashimi讨论) 2022年1月1日 (六) 15:15 (CST)
签名里带div怎么着都会换行吧,这已经被其他的规定阻止了。—— ほしみ 2022年1月1日 (六) 15:26 (CST)

是否有必要增加关于{{重置缩进}}的使用相关内容

参考Special:差异/5531636/5532561,是否有必要对{{重置缩进}}的使用增加强制性规范?针对讨论串前方缩进符超过一定数量因分段导致讨论串错位的情况,要求必须添加{{重置缩进}}?且考虑到讨论版的易用性,该义务不应由所有参与讨论的用户负责,而应由维护组成员负责?(当然其它用户自行添加也无所谓)--北湖3讨论) 2021年12月30日 (四) 10:49 (CST)

(+)带条件同意 支持增加规范,但是要规定多少我估计会造成讨论负担。或许一个非强制的“缩进影响观感,以及讨论串由于缩进错位”会略微好一点。
刚好这一段上面那个下楼梯式的无限缩进可以试着通过重置缩进试试? -- 满身疮痍の花落丿天使 2022年1月1日 (六) 11:22 (CST)
重置缩进目前一般是作为“排版”的一种,所以首先任何编辑者都可以在适当情况下进行;至于是否需要引入强制性的要求,我个人觉得(=)不是很必要( ——C8H17OH讨论) 2022年1月1日 (六) 23:38 (CST)
(▲)同上 愿意排版,就调整一下,不太适合强制。更何况之后可能要引入的讨论扩展没这个东西,不适合写入方针。—— ほしみ 2022年1月2日 (日) 00:07 (CST)
意見(▲)同上,此乃隨緣。—— Eric Liu 創造は生命(留言 2022年1月3日 (一) 06:43 (CST)

關於自動存廢處理的小提醒

像是空白討論頁面、無鏈入的討論頁重新導向(如移動殘留等)、cewbot使用完畢的維護用頁面,這些其實可用機器人幫忙處理,這樣也能減少人力。 --Kanashimi讨论) 2021年12月31日 (五) 06:44 (CST)

如果閣下願意接手工作,那也挺好的。應該有不少任務可以從隔壁借鑒過來用。—— Eric Liu 創造は生命(留言 2022年1月3日 (一) 06:44 (CST)
這邊可以試試。 --Kanashimi讨论) 2022年1月3日 (一) 07:10 (CST)

投票区

正在加载中……
  • 投票开始时间: |
  • 投票结束时间: |
  • 投票总用时 7 天,正在计算中……

已经快一周没有新的发言了,考虑到今天是周末,就先开票了。@AnnAngela蓝羽汇弗霖凯Lyhic星海子Sivlovski玄微子AkizukiSaitouHlwan03Luenshi007Bbrabbit宇文天启平塚八兵衛空翊サンムルVcfch843875618HetmesAskalana不是液氮红石小蝈XzonnC8H17OHChko08022003Bete1geuseLeranjun一位史蒂夫小乃LUO1PTsanconBYin公的驱逐舰泠佛.西尾哈鲁卡Siw19981998Wenzuxiaot珞珝SinonJZHSytus沼泽Bob1301あめろDaigui屠麟傲血贯井羽优的草莓胖次—— ほしみ 2022年1月9日 (日) 13:03 (CST)

补ping参与讨论的自动确认用户@KanashimiBhsdEricliu1912北湖3YOONHA~1.PAR6116G花落丿天使—— ほしみ 2022年1月9日 (日) 13:05 (CST)

管理员

同意
  1. (+)同意 我觉得这次应该没啥问题了吧。—— ほしみ 2022年1月9日 (日) 13:07 (CST)
  2. (+)同意 总体上没有问题,希望移动提案存档的时候能跑个批量替换或者留个重定向。——From 引梦者浊华(讨论) 2022年1月9日 (日) 15:17 (CST)
  3. (+)同意 提案没有跟随移动到萌百讨论空间确实是当年偷懒了,现在补上也行。——From AnnAngela the Bureaucrat (Talk) 2022年1月9日 (日) 21:53 (CST)
  4. (+)同意 没有认为不妥的地方。——丝毫没有存在感的某蓝色管理员讨论) 2022年1月12日 (三) 14:20 (CST)
  5. (+)同意 通篇没有和现行惯例差别较大的地方,几个变动希望能落到实处。--Thus Spoke Sivlovski.讨论」 2022年1月13日 (四) 19:10 (CST)
  6. (+)同意 总体来看没啥大问题。--Lyhic讨论) 2022年1月14日 (五) 14:09 (CST)
反对
弃权

巡查姬

同意
  1. (+)同意 好。--由使用者乐然)撰于 2022年1月9日 (日) 13:13 (CST)
  2. (+)同意 善。——From 泠佛. (讨论) 2022年1月9日 (日) 13:15 (CST)
  3. (+)同意 可我还是觉得提案应该和提案讨论投票分离啊,放在mgp空间的话已经可以实现这个条件了。—— 屠麟傲血讨论) 2022年1月9日 (日) 13:35 (CST)
  4. (+)同意 跟之前那个没区别吧,那我就不看了闭眼投同意了。--Patroller 珞珝 [与我对线] 2022年1月9日 (日) 14:07 (CST)
  5. (+)同意 同意 --MnO43- 2022年1月9日 (日) 14:17 (CST)
  6. (+)同意 我该去改签名了--FIGHT AGAINST OMICRON! ·P. W. T. 2022年1月9日 (日) 14:30 (CST)
  7. (+)同意 无意见-- 小乃讨论) 2022年1月9日 (日) 14:47 (CST)
  8. (+)同意 没有问题。--Vcfch843875618讨论) 2022年1月9日 (日) 14:51 (CST)
  9. (+)同意 吼。--By CHKO (Talk) @ 2022年1月9日 (日) 15:05 (CST)
  10. (+)同意 無異議。 --空翊留言) 2022年1月9日 (日) 15:19 (CST)
  11. (+)同意 冇问题。--94 42 233 2001-8 J-JREDiscussion) 2022年1月9日 (日) 15:30 (CST)
  12. (+)同意 路过随票。 -- 宇文西修ิิۣۣۖۖۖ特拉瑟 2022年1月9日 (日) 15:58 (CST)
  13. (+)同意 今天执行相关处理的时候才意识到旧有方针的缺陷,乐见修订。—— 这是一张遗漏的二饼请联系失主) 2022年1月9日 (日) 17:04 (CST)
  14. (+)同意 我的签名合格否?——From猿渡宇希单推人 贯井羽优的草莓胖次讨论·贡献) 2022年1月9日 (日) 17:09 (CST)
  15. (+)同意 没问题。——bob1301讨论) 2022年1月9日 (日) 19:29 (CST)
  16. (+)同意 没什么可说的,因为没有意见。—— DaiGuitalk」 2022年1月9日 (日) 21:58 (CST)
  17. (+)同意 感觉还行。——芳文厨一位史蒂夫 讨论·贡献 请问您要单推一只小浣熊吗? 2022年1月9日 (日) 23:06 (CST)
  18. (+)同意 无异议。——★Sytus~Talk 2022年1月10日 (一) 00:55 (CST)
  19. (+)同意 完善了讨论制度和提案制度,不戳。--SinonJZH(๑•̀ω•́๑)(讨论) 2022年1月10日 (一) 12:20 (CST)
  20. (+)同意 没有异议。--bbrabbitからの評論 #討論# 2022年1月10日 (一) 16:01 (CST)
  21. (+)同意 无异议。——From 西尾哈鲁卡 (讨论) 2022年1月10日 (一) 16:39 (CST)
  22. (+)同意 沒有異議。--野生的阿卡喵突然出現了並召喚出了她的紙箱!讨论) 2022年1月10日 (一) 16:44 (CST)
  23. (+)同意 没有意见。--以上言论来自于巡查姬007君 _(:3 」∠)_讨论) 2022年1月10日 (一) 19:30 (CST)
  24. (+)同意 行。 あめろ 讨论 2022年1月10日 (一) 19:42 (CST)
  25. (+)同意 无异议-- Welcome to the Hotel California 2022年1月10日 (一) 22:30 (CST)
  26. (+)同意 放置提案的名字空间更改以及签名放置位置的限制两点让我基本满意,其他点静等实行效果。--サンムル讨论) 2022年1月11日 (二) 09:52 (CST)
  27. (+)同意 无异议。—— 冬月下的二重奏 LUO1P 2022年1月11日 (二) 12:54 (CST)
  28. (+)同意 无异议。--Bete1geuse讨论) 2022年1月11日 (二) 13:06 (CST)
  29. (+)同意 善哉--已经是一条死鱼的HetmesAskalana 2022年1月11日 (二) 16:56 (CST)
  30. (+)同意 支持。——「今日も一日がんばるぞい!」(沼泽讨论) 2022年1月13日 (四) 11:01 (CST)
反对
弃权

参与讨论的自动确认用户

同意
  1. (+)同意 这个折中可以接受。——移动版用户 Bhsd 2022年1月9日 (日) 16:25 (CST)
  2. (+)同意 就汴了一句,看着应该没啥问题 -- 满身疮痍の花落丿天使 2022年1月9日 (日) 16:37 (CST)
  3. (+)同意:加油!—— Eric Liu 創造は生命(留言留名 2022年1月9日 (日) 18:41 (CST)
  4. (+)同意 无异议——北湖3讨论) 2022年1月9日 (日) 22:59 (CST)
  5. (+)同意 可以。——6116G讨论) 2022年1月10日 (一) 22:00 (CST)
反对
弃权

▼ 该投票无效,原因:无票权。
  1. (+)同意 虽然看完了也学不会不过反正逐步精简改进总是好的。--木织元讨论) 2022年1月16日 (日) 11:17 (CST)
▲ 该投票无效,原因:无票权。

无票权用户

同意
  1. (+)同意 无异议--TNLHKsign|talk 2022年1月9日 (日) 14:44 (CST)
  2. (+)同意 那必然是进行一个同意的投——甜的白萝卜(讨论) 2022年1月9日 (日) 17:17 (CST)
  3. (+)同意 感谢各位大佬的工作。_USER:YOONHA~1.PAR(留言)2022年1月9日(日)09:42:10(UTC)
  4. (+)同意 夸张点说,赏心悦目。 From 库德里尔 (讨论) at  2022年1月15日 (六) 09:23 (CST)
  5. (+)同意 实话实说,这次没啥问题了。--流浪者-瀧澤さくね討論) 2022年1月16日 (日) 08:19 (CST)
反对
弃权

计票与结论

根据萌娘百科:提案:具有投票权的用户为:【管理员】、【巡查姬】、在讨论阶段参与了提案讨论的已注册达30天、遵守方针的活跃【自动确认用户】。在提案有至少2位管理员参与投票时,【投票有效】。

  1. 投票开始时共有6名参与站务的管理员;其中,
    • 5(+)同意
    • 0(-)反对
    • 0(∅)弃权
    • 1人未投票 (弗霖凯)。
  2. 投票开始时共有35名正式巡查姬;其中,
    • 30(+)同意
    • 0(-)反对
    • 0(∅)弃权
    • 5人没有参与投票(Hlwan03,不是液氮,Xzonn,C8H17OH,公的驱逐舰)。
  3. 共有5名有票权的自动确认用户参与了投票;其中,
    • 5(+)同意
    • 0(-)反对
    • 0(∅)弃权
    • 另有1人投了无效票。
  4. 另有5位无票权用户发表了意见。

当前提案有5位管理员投同意或反对票,大于等于要求的2名,该提案投票有效

统计计票结果,全部投票之同意:反对票数量为 40:0,【同意】票数大于【反对】,且管理员的【同意】票数不小于【反对】,【提案通过】。—— ほしみ 2022年1月16日 (日) 13:45 (CST)