维基百科讨论:机器用户
Flood flag
[编辑]现时很多机器人操作要求编辑被保护的页面,但目前zhwiki没有授予机器人管理员权限的先例,造成了很多操作只能用管理员账号跑,从而导致无法挂上bot flag进而刷掉整版的最近更改。因此,在下想提请在本地启用目前元维基使用的m:Flood flag。
这样管理员可以在执行重复性的、不适合人类进行的操作时,可以给自己加上Flood flag,从而在机器人脚本中提交的bot标记将产生效果并在最近更改中默认隐藏(不会影响通过常规编辑界面做出的编辑)。按照目前元维基的现状,管理员应当仅在即将进行上述操作时加上flag,在进行完成后即行去除。对于该项权限的滥用应当等同于对其它管理员权限的滥用。
在下认为这种方式优于向机器人授予管理员权限或要求管理员每次都向行政员索要机器人权限。故在此提交社群讨论,欢迎提出意见。以上。--Jimmy Xu talk·201 2010年11月18日 (四) 13:54 (UTC)
- (+)贊成。--菲菇@维基食用菌协会 2010年11月18日 (四) 14:10 (UTC)
- (*)提醒,已将方针页翻译完成,请见WP:机器人用户。--Jimmy Xu talk·201 2010年11月19日 (五) 03:29 (UTC)
- (-)反对:請先明確使用機器人的義務再說。君不見User:Shizhao老大認為社群不是對他的機器人授權,而是對他授權,所以他愛怎麼用機器人就怎麼用,不必再申請。而且弄出一堆保護頁的不正是管理員自己嗎?管理員自己太隨便,搞到自己不方便,現在又想擴大權限,結果便是更加隨便。--百楽兎 2010年11月19日 (五) 05:17 (UTC)
- (+)贊成:另外請百樂兔注意,你所說的「管理員自己太隨便,搞到自己不方便」完全是你對此功能的誤解。這個功能是讓大家再看最近更改的時候,可以不會看到一大堆其實是由機器人跑的保護頁面定期維護更新,受益的不是管理員而是整個社群(想在最近更改裡看這些更新的話只要將機器人更改的部分改為顯示即可)。閣下提出的機器人授權問題是另外一回事,請不要攪在一起。--祥龍 (留言) 2010年11月19日 (五) 05:37 (UTC)
- (:)回應:受益?一些管理員仍搞不清楚機器人的操作義務,這個方針又任由管理員自己定義所謂「大量重複性、無爭議的編輯」,並可透過這個Flood flag的方便工具將自己有爭議的機器人的所做所為進一步隱藏起來、減少被社群監測到機會,這就是你所謂整個社群受益+我對此功能的誤解+我把事情攪在一起?中文維基百科的參與者真的很有才。--百楽兎 2010年11月24日 (三) 05:12 (UTC)
- (:)回應:看來閣下的確還是沒有弄懂這個功能到底是在作什麼。這個功能的用途就是將是機器人作的修改就標明為是機器人的修改,而不是因為得透過管理員帳號才能修改而誤認為是由管理員本人進行的修改。另外現在機器人作的修改本來就是預設成隱藏的,此一修改會影響到的只有受保護頁面,而基本上會經常需要修改的受保護頁面多半與首頁有關,例如{{DYK}},若是受到更改很快就會被社群發現。至於其他的受保護頁面不外乎是經常被使用的模板與發生編輯戰的頁面,亦是容易受到社群注意的情形。由此看來,並不存在什麼進一步的問題,閣下的質疑根本站不住腳。--祥龍 (留言) 2010年11月24日 (三) 08:48 (UTC)
- (:)回應:看你的回應真是浪費我時間。我在說什麼,你根本沒有懂而且也不想懂。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- (:)回應:以上的話也可以用在你身上。我已經反駁了你立論的依據,你說的「減少被社群監測到的機會」的問題根本不存在。這個功能的唯一用途就是讓是機器人作的動作就標示為機器人,是管理員本人作的動作就標示為管理員本人做的,僅此而已。事實情況是這些編輯一直在做,而這些其實是由機器人跑的編輯會在最近更改裡顯示成是管理員所做的編輯,造成洗版。如果閣下真要徹底監視機器人的話,那麼應該要求將機器人所做編輯在最近修改裡預設成顯示,而非反對正確標明做出動作是人還是機器人。由此可見,你所要反對和提出的意見根本就弄錯了對象。--祥龍 (留言) 2010年11月25日 (四) 13:02 (UTC)
- (:)回應:看你的回應真是浪費我時間。我在說什麼,你根本沒有懂而且也不想懂。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- (:)回應,如管理员使用此权限隐藏争议编辑则可视为滥用权限。--Jimmy Xu talk·194 2010年11月25日 (四) 12:22 (UTC)
- (:)回應:看來閣下的確還是沒有弄懂這個功能到底是在作什麼。這個功能的用途就是將是機器人作的修改就標明為是機器人的修改,而不是因為得透過管理員帳號才能修改而誤認為是由管理員本人進行的修改。另外現在機器人作的修改本來就是預設成隱藏的,此一修改會影響到的只有受保護頁面,而基本上會經常需要修改的受保護頁面多半與首頁有關,例如{{DYK}},若是受到更改很快就會被社群發現。至於其他的受保護頁面不外乎是經常被使用的模板與發生編輯戰的頁面,亦是容易受到社群注意的情形。由此看來,並不存在什麼進一步的問題,閣下的質疑根本站不住腳。--祥龍 (留言) 2010年11月24日 (三) 08:48 (UTC)
- (:)回應:受益?一些管理員仍搞不清楚機器人的操作義務,這個方針又任由管理員自己定義所謂「大量重複性、無爭議的編輯」,並可透過這個Flood flag的方便工具將自己有爭議的機器人的所做所為進一步隱藏起來、減少被社群監測到機會,這就是你所謂整個社群受益+我對此功能的誤解+我把事情攪在一起?中文維基百科的參與者真的很有才。--百楽兎 2010年11月24日 (三) 05:12 (UTC)
- (+)支持--达师 - 147 - 228 2010年11月19日 (五) 13:58 (UTC)
- (+)支持,方便巡查员盯RC吧。--快龙☀此致敬礼 2010年11月19日 (五) 16:44 (UTC)
- (+)支持:但请不要运行有争议的脚本。--苹果派.留言 2010年11月20日 (六) 15:31 (UTC)
- (+)贊成,另外,我何时“認為社群不是對他的機器人授權,而是對他授權“?--百無一用是書生 (☎) 2010年11月22日 (一) 02:39 (UTC)
- (:)回應:
那看來是我們對bot要求上的理解差異了。我認為社群對bot的批準是出於信任而允許他的傀儡帳號擁有bot許可權,並出於善意推定相信這個用戶會妥善使用bot。而你則認為bot的每一項工作都要取得社群的信任,要有社群的批准才行。…--百無一用是書生 (☎) 2010年10月2日 (六) 11:53 (UTC) |
忙到連自己說過的話都忘了啊?--百楽兎 2010年11月24日 (三) 05:12 (UTC)
- 我的意思是相信这个用户,才会对他的bot授权,对用户授权又没用,又不能让他的bot帐号获得bot权限--百無一用是書生 (☎) 2010年11月24日 (三) 09:10 (UTC)
- (:)回應:既然你認為社群沒有對你授權,你怎麼還敢擅自變更機器人獲得授權的工作呢?自相矛盾。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- (!)意見,同意以上的觀點。機器人的動作應該受到嚴格的限制,機器人的管理人不應擅自做出絲毫變更。115.160.157.41 (留言) 2010年12月8日 (三) 19:23 (UTC)
- (:)回應:既然你認為社群沒有對你授權,你怎麼還敢擅自變更機器人獲得授權的工作呢?自相矛盾。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- 我的意思是相信这个用户,才会对他的bot授权,对用户授权又没用,又不能让他的bot帐号获得bot权限--百無一用是書生 (☎) 2010年11月24日 (三) 09:10 (UTC)
经一周讨论,在下认为已达到共识,交Bugzilla。--Jimmy Xu talk·194 2010年11月25日 (四) 12:25 (UTC)
- (:)回應:又來了,作為正式方針可以這麼不正式就通過了喔?--百楽兎 2010年11月30日 (二) 01:37 (UTC)
- 建议先整理一下目前的机器人的任务。(上次百乐兔提出的意见的问题不知道修正没有,反正我觉得这样下去有一天终会出大乱)—Edouardlicn (留言) 2010年12月2日 (四) 04:18 (UTC)
完成--Jimmy Xu talk·187 2010年12月2日 (四) 14:35 (UTC)
現時此方針之中,標明只有管理員可以使用此權限,然而實際上並非只有管理員才會沖刷「最近更新」,非管理員亦會,尤其持有AWB使用權用戶。如果批量編輯屬於恆常,固然應該另開帳戶並申請機械人權限,但亦的確偶爾會有需要短期大量操作,所以普通用戶亦都應該可以在妥善監察情況下使用「機器用戶權限」。是故,現提請增訂以下條文至《機器用戶方針》。有請諸位定奪。
== 非管理員使用機器用戶權限 == 非管理員亦可短時間內使用機器用戶權限,然而需要有行政員或管理員監察下才可使用,以確保權限使用正確。用戶如有需要,應該在申請時列明工作內容為何,經[[WP:BAG|機械人審核小組]]成員或行政員審核後可取得權限。機器用戶權限不止適用於AWB使用權持有用戶,然後就AWB使用者而言,由於獲得此權限以後,可以轉為全自動操作。所以申請時必須述明是否轉為全自動操作,而若然轉為全自動操作,工作內容則必須符合[[WP:機械人方針|機械人方針]]第二節規定。載有機器用戶權限時,應該只進行預先獲批准操作。如果用戶在獲得權限時,進行未獲批操作,管理員可即時[[WP:BP|封禁]]。當操作完成時,用戶應及時至[[Special:用户权限]]移去權限。如果未有移除,行政員或管理員將會移去權限。
以上。--J.Wong 2017年6月23日 (五) 05:39 (UTC)
- (+)支持:個人是支持,權限申請時表示以認可該用戶,諾用戶不當使用(如那機器用戶作不當的編輯應當被審查是否合適權限)。另外應授予用戶使用完畢則可自行移除機器用戶,以利作其他一般編輯或討論。這部分也請考慮一下。--Zest 2017年6月23日 (五) 06:07 (UTC)
- (-)反对:超速的編輯需要申請機器人。--小躍(撈出記錄) 2017年6月24日 (六) 14:26 (UTC)
- 所以如君所言,管理員都不應該使用此權限?用戶之所以亦有機會需要使用此權限,乃因為就算現時已使用編輯過濾器規限AWB使用者每分鐘只可以作三次編輯,但當使用最高速度時一樣足以洗刷最近更新。機械人與機器用戶,兩種權限分工其實非常清楚,機械人權限是給予附屬帳戶,讓用戶處理恆常繁複工作,機器用戶權限是給予主帳戶,處理短期而繁複工作,其工作量應是數以小時計就能完成。而且該等工作應該只是簡單替換分類、模板等。此等工作使用AWB可以快速完成,但無疑亦是可以洗刷最近更新,阻礙正常巡查。難道要用戶經歷數以月計申請程序,然後去完成數以小時計工作?如此不成比例?兩組權限內容亦有明顯差異。而普通用戶因為本身沒有自帶「noratelimit」,某些動作速率仍然會受限;「apihighlimits」及「nominornewtalk」等權限亦是「機械人」才有,「機器人用戶」沒有。如果用戶只是打算用AWB進行簡單分類或模板替換,機械人有些權限對該用戶而言是根本多餘。
- 與其他編輯於IRC上討論後,認為機器用戶權限審核過程,應與機械人審核過程看齊,應讓機械人審核小組參與審核過程,此議亦合理,遂稍為修改上列提案。
- 以上。--J.Wong 2017年6月24日 (六) 16:14 (UTC)
- 傾向(+)支持,未見其弊。--⌬胡蘿蔔 BOARD · CHEM 2017年6月24日 (六) 19:25 (UTC)
- 可是忽然設想到一個可能:如果一個行事有爭議的良好用戶(比如曾經打編輯戰、加入疑似不中立內容,但非破壞者,亦有明顯貢獻)要作批量編輯,向BAG拿下了權限。在打算開始批量編輯前的一刻,該用戶突然想起自己涉及過的條目爭議已經冷卻好一陣子,便馬上加入自己一直想加的不中立內容,然後立即作批量編輯,完成後除權。這樣,他的濫用行為倒不是難以監察?--⌬胡蘿蔔 BOARD · CHEM 2017年6月24日 (六) 19:33 (UTC)
- 使用AWB修改的話摘要和位元數會非常相近,其中有誤會很明顯,因此提議授予時放至監督列表,使用時段的編輯紀錄可作檢查,任何惡意行為均需嚴懲。--Zest 2017年6月24日 (六) 19:44 (UTC)
- BAG成員、管理員或行政員可使用RTRC進行實時監察。--J.Wong 2017年6月24日 (六) 20:55 (UTC)
- (!)意見機器用戶就處於一種未達機器人的中間權限,機器人審核非常嚴謹,而AWB亦需達到用戶的行為為可信任,編輯修改無誤方可授權,兩者差別在於機器人是定時、長期的修改,AWB為短期,但也有大量修改的時候,為了避免洗刷近期變更,這是一項措施,但不管是那一種方法都要使該用戶了解並遵守使用機器用戶權限時不得作其他不屬於批量修改的編輯,以及批量修改爭議條目未取得共識時的禁封手段。--Zest 2017年6月24日 (六) 19:44 (UTC)
- (!)意見我們要注意,短期/一次性的編輯也可以帶來很大的破壞。無共識下更改分類就是一個很好的例子。為此,目前wp:botpol不但要求機械人申請者需要明確申報任務,而且對那些任務不會獲批也有明確的規定(見sec2.5)。然而,目前的草案並無上述的規定。這等於開放漏洞,讓申請者繞過BAG的監察。我們可以想像,日後可能會有人借此繞過Special:滥用过滤器/45的限制。目前的條文在方方面面都沒有明確的規定,實在難以稱得上創設一項新制度。--Temp3600(留言) 2017年6月24日 (六) 20:11 (UTC)
- 注意AF45僅限建立條目,對已有條目的編輯不受限制。--A2093064#Talk 2017年6月24日 (六) 23:18 (UTC)
- (!)意見我們要注意,短期/一次性的編輯也可以帶來很大的破壞。無共識下更改分類就是一個很好的例子。為此,目前wp:botpol不但要求機械人申請者需要明確申報任務,而且對那些任務不會獲批也有明確的規定(見sec2.5)。然而,目前的草案並無上述的規定。這等於開放漏洞,讓申請者繞過BAG的監察。我們可以想像,日後可能會有人借此繞過Special:滥用过滤器/45的限制。目前的條文在方方面面都沒有明確的規定,實在難以稱得上創設一項新制度。--Temp3600(留言) 2017年6月24日 (六) 20:11 (UTC)
- 已經修改草案,堵塞漏洞。分類及模板替換等細節將會在申請頁述明,以提醒申請者及管理人員。因為此等內容已經在其他方針敘明,所以此處則不贅。而的確《機械人方針》有要求申請者述明將進行工作為何,已在草案加入相關要求。因為當用戶獲得權限以後,使用AWB時,可以轉為全自動操作,符合《機械人方針》機械人定義,所以已述明申請時必須申明操作速度,及如果選擇全自動操作,則須符合《機械人方針》第二段。另外,亦參考《機械人方針》賦權管理員封禁用戶,如用戶進行未經批准操作。另外,亦參考上面用戶意見,使用戶可自行除權。通過以後將提案Phabricator。--J.Wong 2017年6月24日 (六) 20:55 (UTC)
- 建議設計好申請頁面後一次通過所有章程。--Temp3600(留言) 2017年6月25日 (日) 12:02 (UTC)
- 如果再過一段時間沒收到反對意見,就會著手設計申請頁面。另外,刪去首句,該句實為多餘而與後面條文相矛盾。--J.Wong 2017年6月28日 (三) 05:57 (UTC)
- (+)支持--B dash(留言) 2017年7月2日 (日) 07:57 (UTC)
- (+)支持达到一定编辑数且编辑善意、确实有需求的用户使用机器人,但需经过严格审核。--Leiem(留言) 2017年7月7日 (五) 02:23 (UTC)
- 多日未見異議,故草擬申請頁,請諸位過目。--J.Wong 2017年7月7日 (五) 08:07 (UTC)
- (+)支持,寫得不錯。--Temp3600(留言) 2017年7月8日 (六) 16:41 (UTC)
- Stang 2017年7月13日 (四) 11:18 (UTC) 个人建议,申请页部分合并至权限申请页或BRFA。另对以上页面进行了微调。--
- Stang君,兩者流程不盡相同,所以不建議合併,以免產生誤會。--J.Wong 2017年7月13日 (四) 16:38 (UTC)
- 這以後會變成「Wikipedia:權限申請/申請機器用戶權」,還是不屬於權限申請的範圍?--A2093064#Talk 2017年7月13日 (四) 23:22 (UTC)
- 「WP:机器用户/申请」?--J.Wong 2017年7月14日 (五) 03:48 (UTC)
- (+)支持,寫得不錯。--Temp3600(留言) 2017年7月8日 (六) 16:41 (UTC)
- 現公示七日,屆七月廿二日。此前如無異議,則視為通過。--J.Wong 2017年7月15日 (六) 05:14 (UTC)
- (+)支持 Bluedeck 刘晓波 2017年7月19日 (三) 20:18 (UTC)
- 本案通過,已提案要求容許用戶自行移除機器用戶權限。--J.Wong 2017年7月22日 (六) 11:44 (UTC)
- 等等,机器用户没有自动巡查权限,应该禁止或限制机器用户批量创建页面,或加上自动巡查权限。--WAN233 (留言) 2017年7月23日 (日) 09:18 (UTC)
- 批量創建頁面前需經討論。例如AWB申請,而且一般用戶也用不到機器用戶權限。--Zest 2017年7月23日 (日) 13:05 (UTC)
- 要使用機器用戶權限,一般是用以執行半自動或全自動操作。如此,就需要符《機械人方針》第二段規定。該段規定,批次創建條目需要事先獲得共識。若然已經獲得共識支持,同時授予自動巡查亦非難事。--J.Wong 2017年7月23日 (日) 18:11 (UTC)
- 批量創建頁面前需經討論。例如AWB申請,而且一般用戶也用不到機器用戶權限。--Zest 2017年7月23日 (日) 13:05 (UTC)
- Phabricator已按上述申請修改代碼,現機器用戶權持有者已可自行除去權限。--J.Wong 2017年7月24日 (一) 14:09 (UTC)
大量修订版本删除(RRD)导致洗版,但是开启FLOOD处理大量RRD,却又导致RRD的处理绕过所有监察,但是如果公开请求RRD,又导致史翠珊的三角无解问题
[编辑]祝大家返校开心!那么,最近出现了这么一件独特的情况,显示出目前方针的不足,我希望借这个讨论,修补这个方针问题。
管理员接收到了一个用户的大量RRD请求,可能有几百个,这些请求直接放在管理员讨论页上,可能是怕史翠珊再世。这几百个RRD管理员在处理的时候,就洗版了最近更改。被巡查的用户抗议之后,管理员就开了FLOOD,避免洗版。但是FLOOD又说必须是有共识的操作才能FLOOD,RRD请求由于出现在管理员讨论页上,显然不能说是有共识的执行结果。又没有共识,又开FLOOD,就造成这些请求完全躲过所有社区监察功能,显然也有问题。然而,如果为了共识把RRD放在公开版面上,又造成了史翠珊问题。
这样一来,问题显示出来:凡是大量RRD的情况下,以下三个问题无法得到同时解决:1)冲刷最近更改,2)史翠珊,3)社区监察失效。
为了缓解此问题,我希望能够在FLOOD中为RRD开一个例外:如果有大量私下RRD的情况,允许开FLOOD,但是必须在FLOOD+RRD之后,把RRD请求复制到WP:RRD页面上做个记录,这样我认为就解决了上述这个三角问题。此为抛砖引玉,请大家给个看法,谢谢! Bluedeck 2021年8月23日 (一) 11:03 (UTC)
- (!)意見:「把RRD請求複製到WP:RRD頁面上做個記錄」,操作上有點複雜。--蟲蟲飛♡♡→♡℃※留言 2021年8月23日 (一) 11:20 (UTC)
- 不就是在WP:RRD上面新开一个二级标题,把用户放在管理员讨论页上的请求复制过去,然后标记完成就可以了,不一定要按照RRD的标准模版痛苦的填写每一个版本号码。Bluedeck 2021年8月23日 (一) 11:26 (UTC)
- 管理人员是经信任案产生的、已被社群多数成员信任的用户,本身便是共识的结果。如此所言,这类用户使用flood权限理应不需要更多的信任。我们信任某用户,将权力交予他,就应该相信这位用户能够判断出
这些请求
够不够合理,而不是去担心他故意使用权限以躲过社群监督(实际上开了flood也不是完全看不到)。前段时间有一个涉及封禁的讨论我是这样说的,换成RRD也一样。社群可以监督,但那应该在最后,管理人员已经是共识下的可信用户,这意味着他们无需事事等待事前共识,否则只是在浪费社群精力和不必要地拖时间。有人有疑虑就去单独问行事人吧,我相信这些可信用户能够很好地解释自己的行为。朝着管理人员做什么都需要“事先共识”的方向发展可不好。回到问题上,一、用flood,管理员开flood也不需要报备;二三、不要吝啬信任。--安忆Talk 2021年8月23日 (一) 12:07 (UTC) +2- 哦对,蓝桌说的
到RRD页面上做个记录
是可行的。除此之外,我觉得在日志里写原因甚至等有心人来上门问也不是不行。还有就是,知之为知之,不知为不知。--安忆Talk 2021年8月23日 (一) 12:17 (UTC)要技術帝搞個小工具--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年8月24日 (二) 00:04 (UTC)- 手动贴个讨论页固定链接即可,不过我不推荐这样,因为可信用户知道自己在做什么。并且RRD有的时候像是淡化的OS,如无必要,不需示众,导致该隐藏的信息反而被扩散。--安忆Talk 2021年8月24日 (二) 02:23 (UTC)
- 正是,尤其是此LTA的用戶名和編輯有引導社群輿論的意思,不知情的會被其誤導(因為此LTA破壞的頁面太多了,歷史裏還殘留着一堆有引導社群輿論的用戶名和編輯),另外我說啊,如果不想再發生這種情況,除非您們叫那個LTA不再用這些用戶名開賬號和不再做這些編輯吧[開玩笑的]。--MCC214(Sign | Contributions) 2021年8月24日 (二) 12:28 (UTC)
- 手动贴个讨论页固定链接即可,不过我不推荐这样,因为可信用户知道自己在做什么。并且RRD有的时候像是淡化的OS,如无必要,不需示众,导致该隐藏的信息反而被扩散。--安忆Talk 2021年8月24日 (二) 02:23 (UTC)
- 哦对,蓝桌说的
- 去RRD上留言未免太麻煩些......話說這標題也太長了-- Sunny00217 2021年8月23日 (一) 15:49 (UTC)
- 该问题实际上是个佯谬。
- 第一,机器用户方针并未述及“必须是有共识的操作才能FLOOD”,而仅仅是要求相关任务“重复性”和“无争议”:“管理员在进行大量重复性、无争议的编辑时,可以临时授予自己机器用户权限”、“管理员在进行重复性工作时应当使用此权限以避免冲刷掉最近更改中其它维基人的编辑和操作,但这种重复性工作必须是无争议的”、“管理员不得使用此权限作具争议性或不由社群允许的编辑”。
- 第二,若援引管理员方针对管理操作“唯能执行社群共识”的条文来补充论述,实质上此“共识”也不必然等同于“讨论得出的共识”,如共识方针所述,“在维基百科,共识是一种典型但往往含蓄无形的过程。所有没有异议或不被其他编者回退的编辑,均可假定其具备共识”。如果管理员正确地预判到一项批量作业有益无害(特别地,不会引起争议),动用FLOOD权限去执行它,按照以上论述,其仍然是在执行“共识”(只不过这共识的级别相对低而已)。“RRD请求由于出现在管理员讨论页上,显然不能说是有共识的执行结果”的说法也未必能成立。--Antigng(留言) 2021年8月26日 (四) 12:48 (UTC)