维基百科讨论:管理员/存档4
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
留言
管理员权力使用的规范
建议管理员使用权力时必须最少另一位管理员核准无误方能落实。--218.250.198.229(留言) 2016年8月21日 (日) 04:16 (UTC)
- 这是个好习惯,最好先与其它管理员讨论然后再执行操作。事实上,之所以快速删除“一人挂板、另一人核准”就是需要两个人判断才能尽可能保证正确。但是有没有人觉得不应该强制要求我就不知道了。或许可以在某些hard task上面加一些非强制性的条款。比如“执行封禁申诉时,请与原管理员讨论。如无法联系到原管理员,强烈建议与另一位管理员交流。”等等。--Antigng(留言) 2016年8月21日 (日) 04:19 (UTC)
- (!)意见--这增加的是决定成本,而“使用权力”太过管泛,我不确定是否所有的权力需要这样两人搭配,请先限定哪些权力。--❦‽研究及来源 hanteng✉ 2016年8月21日 (日) 04:41 (UTC)
- 这涉及到修改多个方针。例如封禁方针、保护方针、3RR方针等需要管理权限的方针或指引。--秋意假发浓(我已关闭了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 04:45 (UTC)
- 同Hanteng与秋意看法,需要再想想。不过,这一诉求,突显一个问题,有些管理员在做决定时,疑似连事实都没搞清楚、也没有回应用户及社群质疑的准备、甚至不理会,根本上不符合对管理员“说理”的要求。增加谘询另位管理员,有一个好处是,用户及社群有疑问时,另一位管理员也需补充说明。Wetrace欢迎参与人权专题 2016年8月21日 (日) 05:01 (UTC)
- (?)疑问:你的意思是导师制(一个老管理员带新的?)--秋意假发浓(我已关闭了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 05:04 (UTC)
- 同Hanteng与秋意看法,需要再想想。不过,这一诉求,突显一个问题,有些管理员在做决定时,疑似连事实都没搞清楚、也没有回应用户及社群质疑的准备、甚至不理会,根本上不符合对管理员“说理”的要求。增加谘询另位管理员,有一个好处是,用户及社群有疑问时,另一位管理员也需补充说明。Wetrace欢迎参与人权专题 2016年8月21日 (日) 05:01 (UTC)
- 我认为这并没有什么卵用。以目前维基上拉帮结派和抱团打架的现状来看,想使用权力的话找到两个立场相同的管理员不难吧?--20160821ax(留言) 2016年8月21日 (日) 11:05 (UTC)
- 首先感谢您对计划的爱护。管理员的工作中也有比较没那么大争议的(例如删除侵权条目)和争议比较大的(如封禁)。删除侵权条目时如果要每个条目都要两名管理员确认一遍的话,理论上是很好,但实际上减慢处理堆积的速度,而且让本来已经比较枯燥的工作更加繁琐,增加不必要的维护成本。至于封禁,真正具争议的封禁即使两名管理员处理也未必能服众,尤其在目前的社群氛围下。如果任何人对管理员的操作有异议,现在已经有很多机制处理:封禁申诉、存废复核和请求解除保护页面等等,而且维基百科上大部分操作都可逆,所以希望您或其他人能提出一些更具体的方案供讨论。--Lakokat 2016年8月21日 (日) 11:21 (UTC)
- 其实楼上的任期制提案与本讨论的权力规范都是出自同一个原因:对于部分管理员的不信任。--秋意假发浓(我已关闭了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 12:45 (UTC)
- “必须最少另一位管理员核准”说来是好,实际上不见得能够解决管理员的信任问题。从近年的管理员选举,管理员解任投票,反复封禁争议,都可看出中文维基管理员及投票用户存在分党分派的情况,处理事件时甚至先看当事人是谁,再找方针指引自行解读。“必须最少另一位管理员核准”只是多一个同声同气的管理员发声,无助于提高争议性封禁或解封的公信力。--Thomas.Lu(留言) 2016年8月21日 (日) 14:56 (UTC)
- 此一问题必须想出有效办法根治,逐步排除造成争议的乱源,不然社群氛围永远在恶性循环之中。--秋意假发浓(我已关闭了所有通知,所以@我看不到)(留言) 2016年8月22日 (一) 07:26 (UTC)
- (ˉ▽ ̄~) 切~~,恶化为车轮战之前其实不就是相互检查吗?现在更大的问题是有些人拉帮结派,把自己的人推上神台后就狐假虎威,其实肇事的管理员一旦被质疑,应该立即回应,而不是拒绝回答,要不然给人动机不纯,留下把柄罢了。——路过围观的Sakamotosan 2016年8月22日 (一) 08:24 (UTC)
建议在管理员卸任中,新增一条,希望获大家支持。
此举旨在防止部分管理员在任期内不按照规矩行事,我知道此提案肯定会遭到大部分管理员和部分既得利益群体的反对,但想了想还是提上来吧。我们选管理员怎么感觉和原始社会选酋长差不多啊,感觉选上之后个个成皇帝了,了不得了呀。我不否认这些酋长里有明君,但也出了个别暴君,即有人说的所谓民主+独裁。所以建议在管理员卸任中,新增一条,在任期上加一个期限。任期为两年或三年,任满后重新选举一次。大家怎么看?--飞贼燕子(留言) 2016年8月21日 (日) 02:26 (UTC)
- (-)反对,浪费时间。不按方针指引来的管理员直接按照解任程序处理,等三年干什么?--Antigng(留言) 2016年8月21日 (日) 02:41 (UTC)
- 既然问心无愧,又干嘛怕等三年?--飞贼燕子(留言) 2016年8月21日 (日) 03:41 (UTC)
- 浪费时间。zhWP有时间同时开90个RfA?你以为这里是meta的steward 选举或enWP的仲裁员选举?每次仲裁员选举也没有90个人同时选。--Antigng(留言) 2016年8月21日 (日) 03:46 (UTC)
- 既然问心无愧,又干嘛怕等三年?--飞贼燕子(留言) 2016年8月21日 (日) 03:41 (UTC)
- 一点都不浪费时间,当谁最初是怎么取得社群信任的,谁就应该在任职期间自然就懂得就应该怎么把社群的信任保持下去。--飞贼燕子(留言) 2016年8月21日 (日) 04:01 (UTC)
- 对于社群信任的管理员,再开RfA没有意义;对于社群不信任的管理员,有更直接的方法,就是解任投票,也不需要再开RfA。所以再开RfA就是浪费时间,没有好处。--Antigng(留言) 2016年8月21日 (日) 04:03 (UTC)
- 是对管理员滥权没好处吧。--飞贼燕子(留言) 2016年8月21日 (日) 04:05 (UTC)
- 对管理员滥权反而有好处,原来大家觉得管理员做事情不符合方针,只有立即解任投票一条路;现在大家可能会想,也不解任啦,下次不选他就是了。这反而给了滥权管理员三年时间缓冲。--Antigng(留言) 2016年8月21日 (日) 04:06 (UTC)
- 是对管理员滥权没好处吧。--飞贼燕子(留言) 2016年8月21日 (日) 04:05 (UTC)
- 对于社群信任的管理员,再开RfA没有意义;对于社群不信任的管理员,有更直接的方法,就是解任投票,也不需要再开RfA。所以再开RfA就是浪费时间,没有好处。--Antigng(留言) 2016年8月21日 (日) 04:03 (UTC)
- 现在发生的问题不在于管理员“没有任期限制”,而是管理员任免投票被“不恰当拉票”和“拉帮结派”严重影响。--Mewaqua(留言) 2016年8月21日 (日) 04:10 (UTC)
- 同楼上意见。另外,我认为根本问题就是管理员的选任不应采取投票制,应采用资格制,我们应该提拔勤于反破坏与巡查工作的维基人方为正办,擅长写条目的维基人不见得适合做管理员,近期争议已证明了这一点。--秋意假发浓(我已关闭了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 04:17 (UTC)
- 用任期制根本就是想无中生有,塑造维基百科内部有个管理员组成的管理阶层,那么以后要不要顺便开设人民代表大会、人民法院、党分部来多重监督?然后先划定会投反对对象,这样的提案还真是开放讨论。--KOKUYO(留言) 2016年8月21日 (日) 04:11 (UTC)
- (-)反对先恶意假定管理员有问题所以需要定期任免的制度,有可能导致没有问题的管理员在刻意的谋划下被免除职务。会有劣币驱逐良币的现象。--健康欠安 (留言) 2016年8月21日 (日) 04:20 (UTC)
- (※)注意大家放心,此举不会放弃解任投票,而是增加一条任期制,旨在防止部分管理员在任期内不按照规矩行事,我知道此提案肯定会遭到大部分不守规矩的管理和部分既得利益群体的大力反对,但为了长久之计,请大家务必认真考虑。--飞贼燕子(留言) 2016年8月21日 (日) 04:22 (UTC)
- 当然不会取消解任投票。但是不管怎么说,任何人提解任投票是需要有勇气的,而且要有比RfA更大的勇气。如果只有解任投票一条路,很多用户就会鼓起勇气把事情说出来。在维基百科上,只有把事情勇敢地说出来才有价值。如果有了第二条路,相信即使两种制度并存,不少原先选择Rfda的人也会放弃他们的想法。这无论是对促进沟通,还是对及时罢免真正的不当使用权限的管理员都没有好处。--Antigng(留言) 2016年8月21日 (日) 04:29 (UTC)
- (※)注意大家放心,此举不会放弃解任投票,而是增加一条任期制,旨在防止部分管理员在任期内不按照规矩行事,我知道此提案肯定会遭到大部分不守规矩的管理和部分既得利益群体的大力反对,但为了长久之计,请大家务必认真考虑。--飞贼燕子(留言) 2016年8月21日 (日) 04:22 (UTC)
- (-)反对:同Antigng。--4Li 2016年8月21日 (日) 04:27 (UTC)
- (-)反对:同Antigng,浪费社群精力。--Lanwi1(留言) 2016年8月21日 (日) 04:31 (UTC)
- (-)反对:浪费社群精力。--晴空·和岩 讨论页·反互煮·协作计划 2016年8月21日 (日) 04:36 (UTC)
- (-)反对:同Antigng及Lanwi1,或有转移社群注意力的问题。--❦‽研究及来源 hanteng✉ 2016年8月21日 (日) 04:40 (UTC)
- 此提案不能有效反映现状,当前我们有80位管理员,坚持默默做枯燥站务工作的不到一半人数,而会违反方针与指引的又是这少数管理员的极少数,大多数管理员都是遵守方针与指引的。因此应该讨论的是,当管理员自己违规时,社群应有办法对应此事,而任期制并无法解决管理员违规问题。(我承认我还是觉得有设立仲裁委员会或调解委员会的必要)--秋意假发浓(我已关闭了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 04:42 (UTC)
- (-)反对:同Antigng及Lanwi1。Wetrace欢迎参与人权专题 2016年8月21日 (日) 04:58 (UTC)
- (-)反对:有严重违规会影响中文维基运作时应直接提罢免,而无违规疑虑的管理员,纵使只是偶尔执行任务也不会因此造成负面影响,提这种提案只是浪费社群资源。麻烦有闲时间搞这些不如拿去好好编辑条目!--泅水大象™ 讦谯☎ 2016年8月29日 (一) 02:33 (UTC)
关于整合站务各页面的提议
现在站务页面分作很多,例如WP:VIP、WP:存废复核请求、WP:移动请求等等,部分页面的关注程度甚低,懂得门路找对页面提出请求的用户(尤其是新用户)亦不多,导致很多逼切需要解决的站务问题处于积压的状态。因此,我建议将这些站务页面统一归类至WP:管理员协助请求或重新使用Wikipedia:请求管理员帮助也可,这不但便于用户寻求协助,管理员也不需要东奔西跑去解决问题,而且部分问题可能是目前各种站务页面未能涵概,例如索取被删页面纪录、协助解决争议、解答站务疑难、提报游戏维基或扰乱行为、复核其他管理员的决定、修改首页内容等等。整合后,相信有助用户更容易提出请求,而管理员也可以一目了然应对各种问题,从而加强反破坏的效果。目前初步建议将以下站务页面整合:
- Wikipedia:当前的破坏
- Wikipedia:移动请求
- Wikipedia:档案存废讨论/无版权讯息或档案来源
- Wikipedia:请求保护页面
- Wikipedia:需要管理员注意的用户名
- Wikipedia:修订版本删除请求
- Category:维基百科编辑被保护页面请求
- Wikipedia:权限申请
- Wikipedia:合并请求(这个也荒废得太厉害)
我明白技术上可能需要大幅调整,但是如果社群同意整合的话,预期效果应该不错。不知大家意下如何?—AT 2016年9月26日 (一) 01:42 (UTC)
- 可以使用类似以前的管理员公告版模式,将这些页面通过包含或者指引的方式告知这些页面的存在,使用完全整合技术难度将可能会是“史无前例”。——路过围观的Sakamotosan 2016年9月26日 (一) 02:36 (UTC)
- 我初步的想法是制作类似存废复核请求般的提报功能,但是选项作一些变化。例如第一项是“相关页面标题”、第二项是“求助理由”,然后自动生成第三项是“管理员判定”和“个人签名”,存档可以是一个月存一次或两次,每满50项存一次也可以,以目前的技术我想应该做得到,至于与机械人和TW之间的连动就需要技术达人的调整。另外,现Wikipedia:请求管理员帮助其实正发挥您所说的功能,但是效果不佳,因此我希望能够作出改革。—AT 2016年9月26日 (一) 03:35 (UTC)
- (+)赞成站务页面太复杂了。——星耀晨曦(留言) 2016年9月26日 (一) 11:12 (UTC)
- (!)意见可以参考WP:互助客栈的结构:把主要的站务按功能的分类,在客栈首页放置一些目前正在进行的一些重要讨论或者重要的通知。——星耀晨曦(留言) 2016年9月26日 (一) 11:12 (UTC)
- 基本上较热门的话,我比较倾向不整合。例如侵权、速删、存废等等,其他则整合至同一页面,让各种请求能够更灵活地得到处理。—AT 2016年9月26日 (一) 19:59 (UTC)
- (!)意见可以参考WP:互助客栈的结构:把主要的站务按功能的分类,在客栈首页放置一些目前正在进行的一些重要讨论或者重要的通知。——星耀晨曦(留言) 2016年9月26日 (一) 11:12 (UTC)
- 我初步的想法是制作类似存废复核请求般的提报功能,但是选项作一些变化。例如第一项是“相关页面标题”、第二项是“求助理由”,然后自动生成第三项是“管理员判定”和“个人签名”,存档可以是一个月存一次或两次,每满50项存一次也可以,以目前的技术我想应该做得到,至于与机械人和TW之间的连动就需要技术达人的调整。另外,现Wikipedia:请求管理员帮助其实正发挥您所说的功能,但是效果不佳,因此我希望能够作出改革。—AT 2016年9月26日 (一) 03:35 (UTC)
- 可以使用类似以前的管理员公告版模式,将这些页面通过包含或者指引的方式告知这些页面的存在,使用完全整合技术难度将可能会是“史无前例”。——路过围观的Sakamotosan 2016年9月26日 (一) 02:36 (UTC)
- Wikipedia:字词转换/修复请求,Category:封禁申诉?-和平、奋斗、救地球!(留言) 2016年9月27日 (二) 00:23 (UTC)
- 字词转换可以考虑加入。但是封禁申诉者皆被封禁,无法在讨论页以提出请求吧,虽然其他人出来替其申诉的话也不是不可以。—AT 2016年9月27日 (二) 00:28 (UTC)
- 设定让封禁者可以编辑某个Wikipedia名字空间的某个申请封禁申诉站务页面如何?-- 宇帆(普通留言·Flow留言·联络) 2016年9月28日 (三) 04:15 (UTC)
- 这个我不知道能否做得到。—AT 2016年9月28日 (三) 04:17 (UTC)
- 和维基百科:编辑禁制方针差不多吧。——星耀晨曦(留言) 2016年9月28日 (三) 04:50 (UTC)
- 这个在中文维基尚未引入,而且只允许编辑某一页面和禁制编辑某一页面应该有很大差异。—AT 2016年9月28日 (三) 04:54 (UTC)
- 利用过滤器把可以编辑的申述页面以外的页面都禁制,这样技术上可以做到吧。——星耀晨曦(留言) 2016年9月28日 (三) 05:02 (UTC)
- 我不确定。—AT 2016年9月28日 (三) 05:33 (UTC)
- 就算技术上可行,一定会有人滥用申诉,这就是问题。--1233C|严禁互煮|T 2016年9月28日 (三) 05:37 (UTC)
- 滥用的话完全禁止就好了,不成问题。现在封禁申诉也是这样做。—AT 2016年9月28日 (三) 05:39 (UTC)
- 就算技术上可行,一定会有人滥用申诉,这就是问题。--1233C|严禁互煮|T 2016年9月28日 (三) 05:37 (UTC)
- 我不确定。—AT 2016年9月28日 (三) 05:33 (UTC)
- 话说回来,封禁申述是在自己的讨论页加入申述模板,然后自动归类到Category:封禁申诉,而不是封禁用户手动归类吧。——星耀晨曦(留言) 2016年9月28日 (三) 05:42 (UTC)
- 当然是加模板后自动归类。—AT 2016年9月28日 (三) 05:48 (UTC)
- 利用过滤器把可以编辑的申述页面以外的页面都禁制,这样技术上可以做到吧。——星耀晨曦(留言) 2016年9月28日 (三) 05:02 (UTC)
- 这个在中文维基尚未引入,而且只允许编辑某一页面和禁制编辑某一页面应该有很大差异。—AT 2016年9月28日 (三) 04:54 (UTC)
- 设定让封禁者可以编辑某个Wikipedia名字空间的某个申请封禁申诉站务页面如何?-- 宇帆(普通留言·Flow留言·联络) 2016年9月28日 (三) 04:15 (UTC)
- 字词转换可以考虑加入。但是封禁申诉者皆被封禁,无法在讨论页以提出请求吧,虽然其他人出来替其申诉的话也不是不可以。—AT 2016年9月27日 (二) 00:28 (UTC)
有关管理员操作的一个问题
在哪些情形中,管理员可以在未接获报告的情况下直接使用管理员权限进行操作?例如(包括但不限于):
- 直接删除未挂速删模板的页面
- 直接封禁未被报告至VIP的用户
- 直接保护未被报告至RFP的页面
- 直接删除未被报告至RDD的修订版本
……
不能直接进行某项管理动作基本上都是出于避嫌考虑,如第1种情况,一人挂模板另一人执行删除为惯例,这是为了使“问题条目”最少经过两双眼从而避免个人意见的偏颇。
在一些情况下,例如,某spammer大批量新建明显的垃圾广告条目,其中只有一部分被巡查员标记速删,与立即使用Special:Nuke删除全部相比,等所有垃圾条目被挂上速删模板再去删是不是太过于注重过程了?维基百科不是官僚体系。
说到底这也是WP:IAR的使用守则,我们须在WP:CIV的前提下使用WP:IAR来改善维基百科——尤其是在别人对这些管理动作提出意见的时候。--Kegns(留言) 2017年1月6日 (五) 16:24 (UTC)
- WP:CSD:“符合下列准则,而又挂有快速删除模板的页面或文件,管理员可直接删除页面或文件,无需通过存废讨论。”
- WP:BLOCK:“管理员有权将用户封禁,以避免维基百科及其他用户受到破坏或伤害。”
- WP:RVDL:“修订版本删除功能用来校订严重不当的发表及日志项目。允许管理员在依据校订标准下使用。亦可移除某些人身攻击和隐私侵害。”
- WP:PP:“尽管维基百科的宗旨是人人可编辑,但在某些特定情形下,管理员可以对页面设定保护,防止用户编辑或移动。”
- 所以问题的答案很明确,1不可以,234可以。--Antigng(留言) 2017年1月8日 (日) 02:33 (UTC)
- 我觉得那四个都是为了避嫌或是滥权的最后一道防线(虽然还是不能阻止),不过如果同个人持续创造垃圾条目的话可以考虑直接封锁跟直接删除条目,但是还要跟其他人讨论。-Neville Wang 奈威 (留言) 2017年1月8日 (日) 14:01 (UTC)
- 第一个如果是管理员遇到破坏呢?或者处理到一个破坏页面后用nuke清理同一个用户的破坏页面?——路过围观的Sakamotosan 2017年1月10日 (二) 00:38 (UTC)
- BTW,不过没有见过有OP使用过保护中“历史只读”原则,有时想查看删除页面内容就不太方便了。 ——路过围观的Sakamotosan 2017年1月10日 (二) 00:38 (UTC)
- 那就是WP:IAR的问题了吧,比如有人想CSD条目,指明要给这人创建的100个条目csd,那么他没必要挂100个模板,说一句就行。不过我自己从来不想用NUKE,除非哪一天我的bot发抽创建大量无意义的页面。--Antigng(留言) 2017年1月10日 (二) 00:41 (UTC)
将管理员的名字改为复核员如何?
显然管理这个字令人对管理员产生高人一等的印象。虽然权限上来说绝对是这样的
理想化的管理员的工作实际上是透过参考方针、指引、共识,对一个决定(无论这个决定是个人的还是社群的)以客观的角度进行复核并付诸执行,所以也许改为复核员也不错的感觉。
顺便还可以写些复核并非只有复核员才能做,只是只有复核员才能执行等等这类的东西,让管理员更显亲民什么的XD
只是问问--—欢迎参观关注度不足博物馆。以上有签名的留言由R96340(对话)加入。 2017年2月25日 (六) 17:21 (UTC)
- 早期有操作员的说法,因为sysop。—菲菇@维基食用菌协会 2017年2月25日 (六) 17:24 (UTC)
- testwiki:Special:ListGroupRights#reviewer。-- Stang 103 2017年2月25日 (六) 17:28 (UTC)
- 只要新人没“先入为主”的念头,就不会产生维基百科的管理员和其它地方的管理员是差不多的错觉。——꧁༺星耀晨曦༻꧂(留言|2017年监管员选举) 2017年2月25日 (六) 18:56 (UTC)
- 不如叫“资深用户”吧。--persona non grata 2017年2月27日 (一) 02:53 (UTC)
- 这个“管理”只是系统层面的管理,而非社群或者组织的管理。——路过围观的Sakamotosan 2017年2月27日 (一) 09:13 (UTC)
- 我认为重要的是群众对于现时维基管理员产生的印象是什么。权力不对等不是问题,权力不对等的矛盾才是问题(不论是否有明确的制度,权力不对等总会在社会自然产生)。看到阁下使用的删除线,我猜阁下感受到管理员和一般用户的相处不是很和陆。请不要高估管理员称呼的改变带来的帮助,因为权力矛盾的存在和掌权者的称呼没有关系。管理员一字出于英文的Administrator,而“管理”一字给人拥有权威的印象,我建议改名为“行政员”、“事务员”、“常务员”、“理事员”等中性、概括、仅描述工作性质的用字。——愚蠢的人类 2017年2月27日 (一) 12:47 (UTC)
维基百科已有其他权限叫行政员。 +4179计算过程 2017年2月27日 (一) 13:43 (UTC)
- (+)赞成,“管理”一字给人拥有权威的印象--叶又嘉(留言) 2017年2月27日 (一) 14:20 (UTC)
- 好奇,这个问题真的单纯靠改名就可以解决么?--J.Wong 2017年2月27日 (一) 15:17 (UTC)
- 就像“官员”改称“干部”。--Mewaqua(留言) 2017年2月28日 (二) 02:09 (UTC)
- 若真的这么做,我认为算是一个实验的好机会,对结果有一个明确的推测,但事实有可能相异的实验才是最有趣的实验。如果管理员不再被称作管理员,会发生什么事情?并非期待会有什么改变,而是看看会发生什么事情—这才是实验的真谛。--—欢迎参观关注度不足博物馆。以上有签名的留言由R96340(对话)加入。 2017年2月27日 (一) 15:27 (UTC)
- 于是这样一来滥权管理员就变成了滥权事务员了,这真是帮了大忙。:D Bluedeck 2017年2月27日 (一) 23:32 (UTC)
- Template:清洁工--逆袭的天邪鬼(留言) 2017年2月28日 (二) 10:57 (UTC)
- 名字改叫:“朝鲜劳动党”了,所以就是劳动而不是统治百姓了?galaxyharrylion(留言) 2017年2月28日 (二) 11:38 (UTC)
- (-)反对:在下认为没必要。--Dqwyy(谈笑风生)正在沉迷CLANNAD回复请ping我 2017年2月28日 (二) 15:55 (UTC)
- 对改名本身没看法,但我估计真的改了成本会很大,有一大堆显示文字要改,而且不能完全交给bot。 --砜中嘌呤的白磷萃取 打谱 2017年3月1日 (三) 03:22 (UTC)
- (+)赞成,建议改名为“事务员”--Vinct_1998(留言)(叮当呀,谁都喜欢你,小猫也自豪!) 2017年3月10日 (五) 09:11 (UTC)
- (-)反对改名,简单明了,难道还要改成“史蒂芬”吗?--小跃(捞出记录) 2017年3月15日 (三) 01:29 (UTC)
无意见。形象问题。--61.224.18.54(留言) 2017年3月16日 (四) 12:56 (UTC)
- (+)赞成,改名是第一步,不能因为这一步不能立即起效而连这一步都不迈出,在十分饥饿的情况下,第一口饭绝对不会让你吃饱,但难道这就是不吃饭的理由?——平头哥(留言) 2017年3月21日 (二) 13:46 (UTC)
- 如果改名能够大幅减低对“管理员”工作性质的不当幻想,以及增进维基媒体社群的相互尊重,我认为可以试试看。台湾杉在此发言 (会客室) 2017年3月27日 (一) 14:01 (UTC)
- (-)反对,如果改名之后那么所有页面的"管理员"一词将必须通通修改,避免贸然行动,维持现状即可。 4279计算过程 2017年4月4日 (二) 11:56 (UTC)
- (-)反对,显然管理员这个头衔的认知度更高,而且改成复核员的话会名不对事(复核啥?)又容易混淆(比如存废复核员[开玩笑的](?)等)。--Jerre Jiang 讨论│参与清理积压站务 2017年4月4日 (二) 12:08 (UTC)
- (+)赞成改为操作员,高级操作的核验与执行者。有助社群理解职能与义务,也符合sysop=系统操作员的本意,这与常见意义的Administrator(管理员)存在不小差异。复核员就算了,像是校对或复核审计,地位过低、增加误解。如果担心修改所有页面,可以先作为一篇论述或者指引来达成共识而创建和建议使用--YFdyh000(留言) 2017年4月10日 (一) 15:11 (UTC)
- (+)赞成将管理员这称呼改名:之前已在相关讨论中提出类似的建议。至于要改为什么名字,似乎还有讨论空间。个人不是很支持继续使用“某某员”的用法,或许“进阶用户”是个更常见且亲和的称呼方式?--泅水大象™ 讦谯☎ 2017年4月17日 (一) 05:09 (UTC)
- (-)反对,administrator 中外翻译一向是管理员。--Temp3600(留言) 2017年4月17日 (一) 06:26 (UTC)
- 个人认为维基媒体计画的特殊性质,可以不用一昧遵循中外翻译的惯例。台湾杉在此发言 (会客室) 2017年4月21日 (五) 06:37 (UTC)
- (+)赞成,可以试一试。虽说很难改过来,不过形式上的更改也是迈出平等的一步嘛燃灯 谈笑风生 微小贡献 2017年4月23日 (日) 08:36 (UTC)
- (!)意见,其实管理员的意义只在于系统的前台性维护,并没有问题。——路过围观的Sakamotosan 2017年4月24日 (一) 01:07 (UTC)
- (!)意见:很有创意的想法。不过,大厦管理员、社区管理员,都是“服务性质”的管理员。维基百科管理员,依据方针明确是“服务社群”。关键还是管理员群的心态与自我认知。Wetrace欢迎参与人权专题 2017年4月27日 (四) 11:07 (UTC)
- (-)反对:越是想改名称叫朝鲜劳动党,越是证明了骑在老百姓头上作威作福。galaxyharrylion(留言) 2017年5月1日 (一) 13:51 (UTC)
- (-)反对不只有复核工作。--浅蓝雪❉ 2017年5月1日 (一) 20:02 (UTC)
订立密码方针
在2015年12月,英文版有两名ADMIN的密码因使用DOB和6位数字而被破。中文版过去亦发生过管理员被盗号的事件。
为此,我提议订立密码方针,要求管理员以上职阶使用强式密码,并定期接受审查(即基金会人员会定期尝试破解密码)。
--Temp3600(留言) 2017年7月8日 (六) 18:30 (UTC)
刚好有网站能测密码强度[1],不过还是强烈(+)支持设立方针(# 4279计算过程 2017年7月9日 (日) 06:07 (UTC)
(-)反对第一,上述的网站只能算是一个测试网站,严格来说和维基百科扯不上边。第二,维基工具要如何发展此一工具?,第三,如果要这么讨论,不如顺便设个密码为限制好了,过短的密码应重设-Z7504(留言) 2017年7月9日 (日) 12:04 (UTC)- (:)回应网站和提案无关。基金会已在英文版实施本政策,故无须担心无法实行的问题。--Temp3600(留言) 2017年7月9日 (日) 13:21 (UTC)
- 一些补充资料:
- 经管理员测试,原来现在已经不能订立8位以下的密码。大家希望将限制扩展至所有用户,又或增加更多限制吗?--Temp3600(留言) 2017年7月9日 (日) 15:02 (UTC)
- (?)疑问@Temp3600:是请谁测试呢?--Z7504(留言) 2017年7月9日 (日) 15:34 (UTC)
- (:)回应会由security team负责。--Temp3600(留言) 2017年7月9日 (日) 17:48 (UTC)
- security team,慢慢整修版本吧,改(+)支持了--Z7504(留言) 2017年7月10日 (一) 01:36 (UTC)
- (:)回应会由security team负责。--Temp3600(留言) 2017年7月9日 (日) 17:48 (UTC)
- (+)支持具有影响站务权限的用户密码需自我有所防备,当被不法入侵会引响多数页面造成困扰,个人赞同此提议,另外八位数以下在有心与有技术的人在数分钟的数小时内破解,八位元以上的时间差数倍以上,具有较好的保护能力,如果包含用户页上的一些资讯如生日在密码上更容易破解,拒绝傻瓜密码、连号密码。--Zest 2017年7月9日 (日) 16:20 (UTC)
- (!)意见技术上不知道可不可行,如果有人试图破解密码则通知用户(密码多次打错、短时间内多次输入)提醒修改密码或增加第二层验证行为。--Zest 2017年7月9日 (日) 16:20 (UTC)
- 在Phabricator上已有类似提案(T11838︰多次尝试登入失败后发送通知予帐户持有人)。而最后进度报告指已经交付测试。--J.Wong 2017年7月9日 (日) 16:51 (UTC)
- 任何限制密码格式的行为本质上都是缩小密钥空间的行为,并没有意义。维护强壮密码是管理员的责任,必须假设任何管理员至少具备这个能力。Bluedeck 快速存档 2017年7月9日 (日) 22:27 (UTC)
- 其实查核员也应要有这能力吧,不然很难被相信算是个真正的用户查核员(虽然一般密码盗密机率不像傀儡这么多...)--Z7504(留言) 2017年7月10日 (一) 01:39 (UTC)
- 任何限制密码格式的行为本质上都是缩小密钥空间的行为,并没有意义。维护强壮密码是管理员的责任,必须假设任何管理员至少具备这个能力。Bluedeck 快速存档 2017年7月9日 (日) 22:27 (UTC)
- 在Phabricator上已有类似提案(T11838︰多次尝试登入失败后发送通知予帐户持有人)。而最后进度报告指已经交付测试。--J.Wong 2017年7月9日 (日) 16:51 (UTC)
- (:)回应的确,社群信任管理员能管理好自己的帐号。但如果多次使用弱密码,屡劝不听,自然可以作为失职事由要求解职。--Temp3600(留言) 2017年7月10日 (一) 14:09 (UTC)
- 这个不是说已经实施了么?难道我记错了?--百無一用是書生 (☎) 2017年7月10日 (一) 02:13 (UTC)
- 建议@Temp3600:详细说明上述问题?--Z7504(留言) 2017年7月10日 (一) 03:31 (UTC)
- 的确,META方针已经实行。本案目的有二:
- 提供META方针的中文版本。
- 如有需要,给予社群机会讨论是否需增加额外限制,如讨论password audit的次数和方式。--Temp3600(留言) 2017年7月10日 (一) 05:39 (UTC)
- 这个只能是通过技术实现才行啊。规定有什么用呢--百無一用是書生 (☎) 2017年7月10日 (一) 06:13 (UTC)
- (:)回应需要先有本地共识才能交到PHAB,在技术实面上落实。--Temp3600(留言) 2017年7月10日 (一) 14:07 (UTC)
- 这个只能是通过技术实现才行啊。规定有什么用呢--百無一用是書生 (☎) 2017年7月10日 (一) 06:13 (UTC)
- 如果这个密码方针通过后,如何实施呢。这得要求管理员使用高强度的密码吧,如何证明管理员使用了高强度的密码?——꧁༺星耀晨曦༻꧂(留言) 2017年7月10日 (一) 07:24 (UTC)
- (:)回应星耀晨曦的问题:
- 第一,技术上,会向PHAB请求,禁止管理员使用某些弱密码(事实上目前管理员已经不能使用8位以下的密码,这里讨论是否需要再加强)
- 第二,会向wmf安全组请求,让他们定期对本地admin进行密码测试,尝试攻入帐号。如果密码一攻就破,强度自然成疑。--Temp3600(留言) 2017年7月10日 (一) 14:16 (UTC)
- (+)支持为什么要反对呢 ?--我要真普选 Asdfugil (留言 | 签名) 留言于香港特别行政区。 2017年8月16日 (三) 01:22 (UTC)
整理
(我觉得cwek君的问题是很好的重点整理,特搬来此处﹐方便回应。)--Temp3600(留言) 2017年7月10日 (一) 14:56 (UTC)
- 我觉得先讨论几个问题吧:
- 是否支持对ABCO组启用强密码定期例行测试,甚至二步验证功能?
- 基金会是否有相应工作小组允许例行或请求进行密码挑战测试?(看上去已经有了)例行的频率多长?自我申请的话允不允许?
- 如何判断是强密码?或者怎样验证或强密码的要求?
- 三个问题能给出详细方案的话,才好进行确立共识吧。——路过围观的Sakamotosan 2017年7月10日 (一) 07:04 (UTC)
- (:)回应
- 问题一:技术上二者皆可行。ABCO现在已经可以申请2FA,而强密码定期例行测试则需要在获取本地共识后,和基金会安全组再申请。但既然英文组亦有类似计划,无理由中文区弄不出来。
- 问题二:基金会安全组。例行的频率未确定(英文区尚未定案),我个人提议半年一次。自我申请不清楚,但meta看来对低权限用户的密码保安不太在意。
- 问题三:目前meta方针已禁止8位以下密码。如果社群认为有必要,可要求加长,增加大小阶/数字/符号要求,要求定期改密码等等。个人对此未有太大想法,偏向维持目前要求。本案目的主要是新增password audit,但如果社群有意收紧密码要求(如要所有用户使用强密码),当然可以提出。--Temp3600(留言) 2017年7月10日 (一) 15:09 (UTC)
- 如果我来回答的话,结合enRFC的做法
- 支持ABCO组定期进行密码审计,ABCO组可以申请或建议一定要开二步认证(尤其C组)
- 如果基金会支持一经申请能定期自动审计并公布结果的话,就可以申请定期审计计划,并按时公布结果。否则由本地定期去申请审计并接收结果并公布。周期初步为半年,不建议超过一年。个人申请的话感觉太麻烦,每次自己改完密码然后申请审计再说我改了密码没问题的,太别扭了。不要求自行改密码就要申请审计,但不反对自行申请审计。
- 好像现在A组默认开启长度要求,至于其他细则的话,例如大小写数字符号非字典化单词组合或个人公开信息等,可以作为一个至少倡议去约束,如果技术已实现的话,也可以去实行,密码强度也有提供一些强度测试网站,可以用来自我初步测试。en的要求就是长于8字节和非常用密码表en:Wikipedia:Most_common_passwords/10000中则可。——路过围观的Sakamotosan 2017年7月11日 (二) 01:44 (UTC)
- 另外本地群组不建议全部实现密码强度限制,只要重要管理组(即ABCO)强制要求则可,另不知道普通用户有没兴趣允许使用二步验证的设定?——路过围观的Sakamotosan 2017年7月11日 (二) 01:46 (UTC)
- 就算是普通用户也要有一定的密码强度,避免攻破后沦陷为破坏者的傀儡。 4279计算过程 2017年7月11日 (二) 02:44 (UTC)
- 不强制吧,毕竟不是这么多人有这么高的安全需求。——路过围观的Sakamotosan 2017年7月11日 (二) 03:29 (UTC)
- 就算是普通用户也要有一定的密码强度,避免攻破后沦陷为破坏者的傀儡。 4279计算过程 2017年7月11日 (二) 02:44 (UTC)
- 元维基现正谘询是否开放予普通用户使用二步验证。--J.Wong 2017年7月11日 (二) 05:23 (UTC)
- 两步认证太可怕。wikitech上我的帐号就莫名其妙被两步认证锁死了,wmf那边都没办法....所以对这个玩意,我一直心有余悸不敢用--百無一用是書生 (☎) 2017年7月11日 (二) 06:52 (UTC)
技术上怎么检查密码的强弱。。服务器上用户的密码都是被加密过的。——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:25 (UTC)
- 在存入数据库之前是还没有加盐加hash的,而且浏览器提交之前也没有做客户端加密,所以这之间仍是明文,提交前的检验可以在这里检测。而后期审计,无非就是模拟登陆去撞,这是撞的密码会加盐加hash后和数据库存储的对比,并无问题。——路过围观的Sakamotosan 2017年7月12日 (三) 08:54 (UTC)
- 也就是说已经存在数据库里的密码无法检验。在用户主动提交密码的时候检验?——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:59 (UTC)
- 要看是检验什么。--A2093064#Talk 2017年7月12日 (三) 09:08 (UTC)
- 已有的就是做审核,看一些已知的碰撞工具,可能包括彩虹表、字典、常用密码表等去试撞,撞中了就可以认为密码安全有问题了。——路过围观的Sakamotosan 2017年7月12日 (三) 09:28 (UTC)
- 还要检查密码是否有在其他网站使用(如YouTube、Facebook、Google、Niconico动画等)--林勇智 2017年7月13日 (四) 12:06 (UTC)
- 我不喜欢这个提议,密码强度够为何还需检查其他网页,这属私人事情了,其他网站的帐户保安也要自己管,何况刻意尝试密码是否相同会给其他网站或用户造成困扰(FB密码错又爱封解又要时间)。--Zest 2017年7月13日 (四) 12:13 (UTC)
- 如何检查?无法检查吧。--A2093064#Talk 2017年7月13日 (四) 12:28 (UTC)
- 英文版同样因无法检查而放弃此要求,然而我们应提醒管理员们。--Temp3600(留言) 2017年7月13日 (四) 14:05 (UTC)
- 还要检查密码是否有在其他网站使用(如YouTube、Facebook、Google、Niconico动画等)--林勇智 2017年7月13日 (四) 12:06 (UTC)
- 也就是说已经存在数据库里的密码无法检验。在用户主动提交密码的时候检验?——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:59 (UTC)
- 反对限制密码格式和长度的行为。如果要规避弱密码,请使用真正能规避弱密码的方法——信息熵限制。限制格式(大小写、特殊符号等)这种方法对非字典穷举攻击是无效的。好的密码强度算法应该是bin(optimalCompress(passphrase).length)>=80 && entropy(passphrase)>=80。如果真要限制,按这个限制。Bluedeck 刘晓波 2017年7月19日 (三) 20:54 (UTC)
对于“基金会将对管理员的密码进行定期查核”这一点,英文版的方针里也早有类似的内容,但是似乎也并没有落实。的确有能力实现吗-- Ben.mq 2017年8月5日 (六) 21:02 (UTC)
添加一些新限制
- 为了进一步提高帐户可靠性,建议采取下列措施。
所有管理员都需使用Template:User_committed_identity或类似措施。中文版对本项认知过低,不宜强行开展。- CUer的选举中,增加一条必答题:你会在上任后启用2fa吗?如不会,请解释。
- 对现有的cuer,邀请他们补答,并将结果存档。
- 草稿:密码方针已初步完工。
- 为了方针的一致性,需在Wikipedia:管理员的离任#解任理由增加"多次违反密码方针"一项。--Temp3600(留言) 2017年7月26日 (三) 07:19 (UTC)
- PING人回来@TEntEn4279、Z7504、蘭斯特、Wong128hk、Bluedeck:--Temp3600(留言) 2017年7月27日 (四) 19:51 (UTC)
- PING人回来@Shizhao、cwek、A2093064、D2513850:--Temp3600(留言) 2017年7月27日 (四) 19:57 (UTC)
- (+)支持:顺便修改了对应连结下--Z7504(留言) 2017年7月27日 (四) 19:56 (UTC)
- committed identity很头痛啊。首先一个问题是社群里有几个人知道committed idnetity的protocol是什么?我看并不多。committed identity需要绝大多数参与成员都拥有很高的程序意识,而且一旦设定不能更改,原像一但丢失,就再也无法证明身份,而且无法重新设定,并且所有社群成员必须不承认重新设定的散列值。请问设定committed idnetity的人和社群有这个觉悟吗。一年前,我曾经公开过一次自己的身份原像,但是我可以肯定地说:直到现在为止没有一个人去验证过,因为我使用的算法是一个罕见算法,网上没有现成的验证程序,也没有人来问我要验证程序,也没有人来问我要散列paper去编程,也没有人来问散列强壮型证明。这样的committed identity等于没有。而且散列值分布式存储也是一个头很大的问题。我的结论是committed identity在中文维基百科基本无用,安全性就只能靠良好的密码practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
- 确实如此。故改为建议,望日后有足够认为后再立为方针。--Temp3600(留言) 2017年7月31日 (一) 08:47 (UTC)
- committed identity很头痛啊。首先一个问题是社群里有几个人知道committed idnetity的protocol是什么?我看并不多。committed identity需要绝大多数参与成员都拥有很高的程序意识,而且一旦设定不能更改,原像一但丢失,就再也无法证明身份,而且无法重新设定,并且所有社群成员必须不承认重新设定的散列值。请问设定committed idnetity的人和社群有这个觉悟吗。一年前,我曾经公开过一次自己的身份原像,但是我可以肯定地说:直到现在为止没有一个人去验证过,因为我使用的算法是一个罕见算法,网上没有现成的验证程序,也没有人来问我要验证程序,也没有人来问我要散列paper去编程,也没有人来问散列强壮型证明。这样的committed identity等于没有。而且散列值分布式存储也是一个头很大的问题。我的结论是committed identity在中文维基百科基本无用,安全性就只能靠良好的密码practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
- (+)支持:不能用低密码强度的密码(包括但不限于GitHub的资料或密码强度条目所提及的密码)--林勇智 2017年7月28日 (五) 08:25 (UTC)
- (?)疑问哪些会成为方针,Draft:密码方针而已吗,还是CUer和User_committed_identity也是?--A2093064#Talk 2017年7月28日 (五) 09:05 (UTC)
- (:)回应那部分开放给大家讨论,我未写进草案里。--Temp3600(留言) 2017年7月28日 (五) 12:33 (UTC)
- (!)意见:根据“噗浪技术部”在噗浪的贴文,被骇客入侵的帐号所使用到的密码大部分为其他网站泄漏的帐号密码--林勇智 2017年7月28日 (五) 12:46 (UTC)
- 然而我们无法检查维基人是否重用了密码;最多只能在他们因重用密码而被盗号时处罚他们而已。--Temp3600(留言) 2017年7月31日 (一) 08:47 (UTC)
结论?
- 近日已无讨论。既然如此,决议:
- 在草稿:密码方针之上,添加Cuer必答题"你会在上任后启用2fa吗?如不会,请解释。",及修改对应Wikipedia:管理员的离任#解任理由。而WMF方的定期密码检查,则初步定为半年一检。(这个要和WMF相讨后才有最终答案)
- 现公示七日。--Temp3600(留言) 2017年8月3日 (四) 15:03 (UTC)
- Cuer必答题可直接加入{{RfA}}模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
- 无法执行。下面说明。试想,必答题写好了,请问CUer怎么回答社群算满意呢?我有这么几个答案,你们看你们满意吗:
- 我不用2FA因为我经常损坏手机,2FA会把我自己锁住。我使用24位强密码。
- 我不用2FA。因为我使用24位强密码足够强,不想再麻烦。
- 我不使用2FA,我使用8位强密码。
- 我不使用2FA,因为我没有手机。
- 我不使用2FA,我定期修改密码。
- 我使用2FA,同时我的密码提供40位安全。
- 我使用2FA,同时我的密码提供80位安全。
- 想好之后,看看我怎么评论这些答案的,然后你是否觉得这仍然是一个可执行的提议。Bluedeck 2017年8月5日 (六) 06:58 (UTC)
- 回答得好不好由社群自行决定,如果有人觉得答得不好,自然会追问,或是投反对票。--Temp3600(留言) 2017年8月6日 (日) 03:28 (UTC)
- 你这是想吧问题丢给社群,我正是觉得这样不可行才有此评论——社群的密码学知识不足,无法判断,甚至不知道自己无法判断一个候选人提供的密码信息是否在可能安全的范围内。Bluedeck 2017年8月10日 (四) 01:05 (UTC)
- 回答得好不好由社群自行决定,如果有人觉得答得不好,自然会追问,或是投反对票。--Temp3600(留言) 2017年8月6日 (日) 03:28 (UTC)
- 无法执行。下面说明。试想,必答题写好了,请问CUer怎么回答社群算满意呢?我有这么几个答案,你们看你们满意吗:
- Cuer必答题可直接加入{{RfA}}模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
- 另外,就“修改对应Wikipedia:管理员的离任#解任理由”而言,个人无法理解这句。是要为提高保安而创造另一个保安漏洞?如此解任岂不等于昭告天下该人帐户不安全,欢迎去攻击?--J.Wong 2017年8月5日 (六) 08:25 (UTC)
- 英文版将“把无法保障自己帐户的管理员解职”的权力交给了ARBCOM,但中文版没有arbcom,只好将这项权力交给社群了,不然本项无法执行。--Temp3600(留言) 2017年8月6日 (日) 03:33 (UTC)
- (?)疑问这个密码方针草稿的一部分是基于WMF会对管理员的账号进行安全审查。是否有数据说明WMF会定期审查管理员账号?如果没有,那么这个方针就没有强制性,谁违反了这个方针都不知道。——꧁༺星耀晨曦༻꧂(留言) 2017年8月5日 (六) 21:15 (UTC)
- 这一项的详细内容要和WMF相议才有最终答案,但要先有本地共识才可以提上去PHAB。--Temp3600(留言) 2017年8月6日 (日) 03:25 (UTC)
- 意思是,得有本地共识,WMF才会对zhwiki的管理员进行安全审查?——꧁༺星耀晨曦༻꧂(留言) 2017年8月6日 (日) 06:04 (UTC)
- 正是如此,只能摸着石头过河。--Temp3600(留言) 2017年8月7日 (一) 14:39 (UTC)
- 不建议作为方针,作为指引尚可。--百無一用是書生 (☎) 2017年8月8日 (二) 01:47 (UTC)
- @Shizhao:这个与WMF谈判有关,我不确定拿指引过去是否可行。--Temp3600(留言) 2017年8月11日 (五) 16:39 (UTC)
让我正经地谈一谈这个问题:
- 作为方针而言,它没有可操作性:虽然可以要求WMF去检查,但是仍然无法在本地判断方针是否已经得到执行。“违反上述要求的管理员可能会被暂时除权,直到他们解决保安问题为止”,那么本地社区如何得知他违反要求和解决问题呢?
- 它没有解决问题:因为强密码不意味着安全,而且安全不一定必须通过强密码来实现。另外证明自己身份的方法很多,“User committed identity”只是其中一种,而且我们也无法保证管理员们能够正确地使用这个工具(所以幸亏没提出强制要求来命令管理员使用这个东西)。
- 后果过重:发现问题解决就行——改个密码而已,没必要以“除权”来威胁。当然我们可以威胁“一旦账号被盗并且产生了严重后果,那么会导致除权”,相比之下这个更实际吧,而且同样可以起到督促保障账号安全的作用。
- “添加Cuer必答题你会在上任后启用2fa吗?如不会,请解释”这个问题有很多缺陷:
- 2FA只是保护安全的方式之一,我们为什么非要通过这一种方法来解决安保问题呢?如果非要问,不如问“你采用了哪些办法来保护账号安全?”
- 前面Bluedeck已经提到,社区没法对答案进行评估,或者说因为大家可能并不懂这个东西,得出的结论很可能是偏颇的。一个只在维基百科有活动的管理员可能只要开了2FA,密码设成123456789也无所谓,而在各个网站注册账号的管理员即使把密码设到20位也有安全风险——实际上是哲学问题。
- 续这个问题,对于维基百科而言,10位密码和100位密码对提高安全程度来说可能没什么区别。拒绝常见弱密码已经足够。
- 监督员也是签署过隐私协议的人,难道监督员不需要回答吗?为什么只有查核员需要回答这个问题呢?
- 虽然我们没法要求管理员必须遵守方针,但是我们可以“强烈建议”,而且以实际后果进行威胁“一旦真的出事了,……”
- 用一句话总结一下:“密码方针”是君子协定,而且其出发点有偏差,所以可以考虑换角度思考(账号安全)、降低成建议级的要求(例如星耀晨曦所言)或考虑修订解任方案。
--逆袭的天邪鬼(留言) 2017年8月13日 (日) 12:34 (UTC)
- 与数位维基人交流后,在下决定撤回此提案,愿日后由更熟识本方面的用户处理帐号安全问题。--Temp3600(留言) 2017年8月16日 (三) 17:28 (UTC)
- 虽然这个方案不太可能通过成为方针。但是可以在这个基础上,建立一个建议用户提升自己账户安全的指引。——꧁༺星耀晨曦༻꧂(留言) 2017年8月16日 (三) 19:06 (UTC)
- 同意星耀晨曦--百無一用是書生 (☎) 2017年8月17日 (四) 02:28 (UTC)
通知︰管理员权限修订
|
|
因应最新技术修订而特此公告。--1233|点此与此废青展开激情对话 | 千错万错都是阿道夫的错 2017年9月28日 (四) 10:57 (UTC)
- 结构化讨论特质这个翻译有点难以理解。--Kuailong™ 2017年9月28日 (四) 15:48 (UTC)
- flow开发团队决定更改名称为结构化讨论。——꧁༺星耀晨曦༻꧂(留言) 2017年9月28日 (四) 23:51 (UTC)
- 好像技术版有机器人通知过吧,但是现在重新起的这名字有点尴尬啊。结构化讨论……—云间守望 · 在此留言💬 2017年9月29日 (五) 00:45 (UTC)
大量帐户建立者方针及管理员方针修订
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
承上次讨论及公示结果,有用户对大量帐户建立者方针及管理员方针作出前列修订。谨此通知。--J.Wong 2018年6月26日 (二) 08:56 (UTC)
- 稍为再作修订及删去不能授予自动确认用户要求。自动确认用户本来就有相关权限,所以没有需要特别要求不可以这样做。多馀权限移除就是了。--J.Wong 2018年6月26日 (二) 09:11 (UTC)
- 注:此次修订亦包含管理员能够更变用户的档案移动员用户组资格的事实性修订。--1233( T / C) 2018年6月26日 (二) 09:19 (UTC)
- 不反对。SænmōsàI'll find a way, or I'll make one. 2018年6月26日 (二) 13:16 (UTC)
- 等待Phabricator部署修补程式,暂时请勿存档。--J.Wong 2018年7月5日 (四) 03:26 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
提议修订Wikipedia:管理员#避嫌部分内容
未完成,提案人请求关闭讨论。如日后对管理员内文有其他问题者,再自行开个讨论串即可。--Z7504非常建议必要时多关注评选(留言) 2020年2月25日 (二) 02:13 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
在下近期处理速删请求时,有遇到TW自动删除页面附带的讨论页的情况,从方针角度,是页面虽符合G15标准,惟未有他人提案,故此并不符合Wikipedia:管理员#避嫌中的有关规定。为避免繁琐,在此提议修订条文。重定向页同理。
|
|
以上。--Hamish论 2020年2月22日 (六) 05:38 (UTC)
- 我建议在提议条文中明示这是G15所允许的。ꓢꓯꓠꓟꓳꓢꓮ COVID-19 2020年2月22日 (六) 06:49 (UTC)
- 其实一向都可以在删条目时直接删去讨论页等孤立页面,而不须等机器人提删,而永封用户甚至0解封后,也不用提删,而直接g8删去永封模板。--虫虫飞♡♡→♡℃※留言 2020年2月22日 (六) 07:10 (UTC)
- (&)建议:此外,管理员大量删除破坏者的页面,也是无须提删,因此可能加注则较容易处理;或者修改g8及g15也行。不过不改,也问题不大,因为这算是IAR,过去多年都是这样处理。--虫虫飞♡♡→♡℃※留言 2020年2月22日 (六) 07:44 (UTC)
- 这算个传统吧,大部分都是这样做的,既然要IAR,我的想法是在方针中明确说明,当然要IAR也不是不行。--Hamish论 2020年2月22日 (六) 10:48 (UTC)
- (?)疑问,何谓“前述要求”?在Wikipedia:管理员中并没有提到有关前述。--街燈電箱150號 开箱维修 抄表 检验证明 2020年2月22日 (六) 09:01 (UTC)
- 那个“前述要求”是指“管理员不得删除自己提议删除或者投票删除的页面”这个,原文措辞不当,已修改。--Hamish论 2020年2月22日 (六) 10:48 (UTC)
- (?)疑问:虽然管理员也可以对条目提报快速删除,但如果条目明显符合快速删除准则,为什么不直接删掉,还要经过提名程序?还不如管理员自己订内规,哪些情况可以不经提名直接删除就好(我也相信管理员内部会有如此共识),这样也不用动到这条。Poem(留言) 2020年2月22日 (六) 14:07 (UTC)
- 基本上所有页面都不能直接删去,但有些如g15,有些管理员会等机器人提删,有些不等,删去等于符合IAR,即操作对维基有实际好处才用这条,g8是不可能提删,因为全永封用户页是被全保护的,删除以便移动也不可等其他人提删。大量删除破坏者页面,是运用IAR,即对维基有好处。维基对于页面的删除是很审慎的,如果管理员可以随意删除,很多政治条目肯定会被无故删去。--虫虫飞♡♡→♡℃※留言 2020年2月22日 (六) 14:41 (UTC)
- 改G15就可以了,无必要改这条。--SCP-2000 2020年2月22日 (六) 15:16 (UTC)
- 在相信管理员会谨慎使用wp:IAR下,我不认为这条需要写得很明;写得太明白反而绑手绑脚。在看不出修改后会带来助益下,不赞同这个修正案。Poem(留言) 2020年2月23日 (日) 04:24 (UTC)
- (▲)同上,社群共识这种属WP:IAR就好了-- Sunny00217 2020年2月23日 (日) 12:29 (UTC)
- 在下遵守社群共识,留题待其余意见,亦可由其余维基人自行关闭。--Hamish论 2020年2月24日 (一) 13:07 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
建议管理员三权分立
依部分用户所请关闭。SANMOSA SPQR 2020年11月9日 (一) 07:09 (UTC)
- 下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
诚然,现在的维基百科已经很稳定了,但我仍不能相信以后会不会发生由于管理员权力集中而导致的灾难,或许可以说,这是一定的,管理员可以立方针,可以处罚,还可以执行处罚,我想起了一句话“当立法者,司法者,和行政者三者在一起的时候,就没有任何自由了”虽然我似乎有些杞人忧天,但从另一个角度来讲,把三个职位分开或许更有效率,我的意见是将现有管理员拆分为三个职位,分别是
- 方针设立管理员
- 判罚管理员
- 处罚管理员
方针设立管理员只能完成对于方针的建设和修复,判罚管理员只能对方针做合理解释做判罚(合理解释即为不超过语义,比如某路说禁止驴马通行,而有一只骆驼过去,是不应当被判罚的)另外,我认为如果被判罚者在违反方针时是违反的,但方针日后修改说明他不需要被罚,那他就不被罚,而其他的情况均应当以判罚时的方针为准,处罚管理员应当只处罚判罚管理员所要求的判罚,并不能加减处罚,而且,处罚管理员有权驳回处罚,并要求其他判罚管理员重新判罚。这是我对维基百科管理员职位的意见,望各位采纳 --Catowen 2020年11月8日 (日) 00:45 (UTC)
- 管理员有避嫌规则;方针是社群讨论的结果;其他管理员都可以处理不合理封禁。怎么说呢…建议您还是先完整地看一下与这些有关的规则。--安忆Talk 2020年11月8日 (日) 01:20 (UTC)
- 设立方针及提议设立方针非管理员之专利。SANMOSA SPQR 2020年11月8日 (日) 02:50 (UTC)
- 题主所述的问题是真实存在,但我认为这问题无法解决。这就好比小国在联合国大会提案要求取消安理会五大流氓的一票否决权,必然会被大国一票否决。--Remaining silent is not Majority's fault. 2020年11月8日 (日) 04:24 (UTC)
- (-)反对:理据:
1.管理员需避嫌。
2.管理员依方针行事,而方针由社群讨论得出。
3.任何管理员皆可处理任何不合理封禁。
4.至于处罚管理员:"管理员没有任何高于其他用户的特权,唯能实现社群讨论所得的共识"(WP:Sysop)。
以上。
题外话:要是真这么搞了互助客栈是不是该易名了?
--光猫猫 Talk理性、证据、辩论 2020年11月8日 (日) 05:15 (UTC)
- 此外,若说三权:立法权在社群、行政权在基金会、司法权在管理员。--光猫猫 Talk理性、证据、辩论 2020年11月8日 (日) 05:19 (UTC)
- @Catowen:(!)抗议设立“方针设立管理员”。现行制度,方针是由社群共识决定的,任何维基百科编者,无论资历深浅,都有权提出方针提案或修正案,且通过与否,要经由社群共识检验,若社群无共识,方针提案就不应该通过。如果订立方针变成一个职位,不就变成皇帝了,维基帝国危机帝国维基危机。哪会自由,直接独裁化了吧,这种提案必须(!)抗议抗争到底。小心到时基金会行动直接把中文维基给关掉,咱们都不用玩了。-- 来人啊,喂宫子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年11月8日 (日) 08:43 (UTC)
- 建议你维实施议行合一制度,选出维基议会,在上面再选一个议会的理事会,再分出三个权来,必要时维基基金会中央可以直接把议会及其理事会解散了。[开玩笑的]--向前进!向前进!朝着胜利的方向!(留言) 2020年11月8日 (日) 12:55 (UTC)
- 我只能说楼主了解管理员制度后再来……Fire Ice 2020年11月8日 (日) 13:14 (UTC)
- 管理员当然有特权,可以自我解封,所以有没有什么办法阻止管理员自我解封。--Googol19980904(留言) 2020年11月8日 (日) 14:19 (UTC)
- 现在管理员又能自我解封了?我记得上次测试的时候,自己把自己封禁后,还是叫别的管理员解封的.....--百無一用是書生 (☎) 2020年11月9日 (一) 02:00 (UTC)
- 应该不行吧,要么就是Googol19980904致远星归来,要么请一位管理员亲身验证下。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年11月9日 (一) 03:22 (UTC)
- 那2019年4月18日 04:12 Shizhao 解封了Shizhao、2017年5月10日 06:47 AT 解封了AT和2017年10月5日 23:43 雾岛圣 解封了雾岛圣是什么意思?现在不能自我解封了?--Googol19980904(留言) 2020年11月9日 (一) 04:22 (UTC)
- 我记得看过一个设置,是限制了这种自解封的。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年11月9日 (一) 05:34 (UTC)
- 现在管理员又能自我解封了?我记得上次测试的时候,自己把自己封禁后,还是叫别的管理员解封的.....--百無一用是書生 (☎) 2020年11月9日 (一) 02:00 (UTC)
- 月经提议。🌜山西特产批发零售™️🌽🌶️🍎🍠🐓🐐(留言) 2020年11月9日 (一) 03:09 (UTC)
- Snow. 了解维基制度后再来,连怎样运作都不知道就先别提案-某人✉ 2020年11月9日 (一) 03:43 (UTC)
- 本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。