維基百科

維基百科討論:機器人方針/存檔一

< Wikipedia talk:機械人方針
由Jimmy-bot在話題對維基百科:用戶頁、維基百科:機器人方針及相聯頁面的合併更新上作出的最新留言：4 年前

提議於本地設置機器人審核員專門權限

最新留言：7 年前194則留言22個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月21日 (二) 11:21 (UTC)。

前期討論

如題。希望本地能設置相關權限（現今中文維基百科負責批核機器人權限與功能者為WP:行政員，英文維基百科則有Bot Approvals Group）。詳述如下：

為什麼要這麼做？
  1. 當今Wikipedia:機器人/申請有許多積壓（而且還不包含因為太多積壓而導致失去/降低意願的潛在申請），現有活躍之行政員數量過少，無暇應付。
  2. 行政員不一定了解相關技術，這只是行政員事務的一部分。根據WP:行政員：「行政員須具備的能力：在出現複雜情況的時候，決定投票共識及結論，並能有效地對這些決定做出全面解釋」，對於機器人相關領域的理解則非其所要求的。
  3. 由於機器人申請的特殊性，需要有專精相關領域的成員協助判斷。如果不熟相關領域的行政員僅依共識而造成誤判，可能會造成大量的錯誤發生。
  4. 反之，如果交由熟悉相關領域之受信任用戶判斷授權，較為適當。
  5. 方便熟悉相關領域之受信任用戶協助處理積壓，而不需要等到自己成為行政員之後才能處理。「只是為了走過場而完成程序並不是維基百科的方針」。
可行嗎？會不會產生什麼問題？
  1. 當今中文維基百科有很多活躍且熟悉相關領域的非行政員（包含管理員）受信任用戶，應能解決當前處理人力不足之問題。
  2. 雖然不一定能如同en:WP:BAG那麼多人[1]，但是本地的事務量也相對沒那麼多，而且程序上應尚不至於需要搞得那麼複雜（維持現有程序應該夠，頂多微調一下），所以應不成問題。

以上，不知大家覺得如何？-和平、奮鬥、救地球！（留言） 2017年1月26日 (四) 11:58 (UTC)

實行問題

原則上不反對，唯有以下數點:

1. 選拔方式。行政員有民意支持，故可一人獨斷。審核員應否以選舉產生?
2. 權力運用。審核員應以小組方式投票通過一項目，或可一人決定?如機器人運作出現問題，審核員應否負連帶責任?
3. 不活躍/解職規定。在何種情況下可對審核員免職?
4. 管理員會否自動成為此小組成員?

以上，望解答。--Temp3600（留言） 2017年1月26日 (四) 15:11 (UTC)

對於BAG組的選拔，我建議有持有現役機器人的用戶可以優先。——路過圍觀的Sakamotosan 2017年1月27日 (五) 01:16 (UTC)
「優先」指的是參選的資格?投票的資格?--Temp3600（留言） 2017年1月27日 (五) 04:36 (UTC)
參加BAG的。——路過圍觀的Sakamotosan 2017年1月27日 (五) 05:08 (UTC)
對於BAG組的選拔，我建議有持有現役機器人的用戶可以優先。——路過圍觀的Sakamotosan 2017年1月27日 (五) 01:16 (UTC)
個人意見：
  1. 首先申請者需要有一定的技術背景和經驗。因此我認為申請者首先需要是持有現役機器人的用戶或管理員。由於機器人的操作可能會在短時間內影響大量條目，所以審核員應該是需要被社群成員所信任的，故應可採用社群推選的模式。
  2. 這點可以考慮。不過這也需要考慮到審核員人數多寡，如果太少人的話我認為只要沒有其他審核員反對，一位審核員通過即可（不過當然要給其他人有審視的時間）。至於連帶責任，則視情形交由社群決定。若嚴重程度上確有必要則可將其免職。
  3. 不活躍規定同巡查回退管理行政員。其餘部分免職的話如果是社群推選，則可罷免，若否則WP:申請解除權限。
  4. 行政員可自動成為此小組成員（畢竟現在的情況就是這樣），至於管理員的話可進一步討論。
以上。-和平、奮鬥、救地球！（留言） 2017年1月27日 (五) 05:09 (UTC)
應注意本案並非微調程序就能解決。BAG本質為一諮詢團體，雖無實質權力，但將對目前體制的權力安排構成重大影響。光是BAG applications 應否放進RFA就是個大問題了。本人傾向不放。--Temp3600（留言） 2017年1月29日 (日) 13:42 (UTC)

我覺得方針里其實有一個阻礙審批的問題：「在經過一段時間的討論後，行政員將根據社區共識批准或拒絕申請」。這裡以及具體的規則上都沒有明確定義時間的長短。這樣導致的一個後果就是在審批時往往認為討論不充分，因此長期放置。此外，這裡的共識倒不是要走投票，因為還得有技術上的考慮。因此，我想提議參考Wikipedia:共識#過程中的「沒有異議或不被其他編者回退的編輯，均可假定其具備共識」的說法，為機器人的審批設定一個終止時間：在這個時間點之前，如果其他用戶提出的所有問題都得到了正面的回答，且提出問題者或表示對回答滿意，或沒有繼續追問，就認為共識存在且通過：唯一例外是審批者具有否決權，以確保專業角度上機器人不會引發問題。—菲菇＠維基食用菌協會 2017年1月27日 (五) 05:27 (UTC)

(！)意見：如果有最後幾[天時分秒]追問的話，會來不及回答從而影響審批。要不回答時間比終止時間延長一些，像動員令那樣。 --白磷變成了紅磷並祝您春節快樂~萃取 打譜 2017年1月30日 (一) 15:25 (UTC)
我不打算制訂硬性的結束時間。--Temp3600（留言） 2017年1月30日 (一) 16:43 (UTC)
的確有卡在最後幾[天時分秒]的情況。因此，可否考慮可以將結束時間設置在最後一次有效討論之後的XX天（類似但不等同於互助客棧的存檔規則）？這樣既能保證充分討論，也能避免卡時間的情況出現。此外，此處的「有效討論」不包括插科打諢和純粹的支持、反對及其單調附加語（如「好」、「不錯」，「贊成」，「就應該怎麼做」，「這樣不對」，「1024」等）。--菲菇＠維基食用菌協會 2017年1月31日 (二) 07:10 (UTC)

可參考英文版

英文版目前BAG制度如下:

申請者不一定是持有現役機器人的用戶或管理員。當然，這種情況下提名極難通過。事實上組裡大半人都是管理員。
需社群投票通過，但不設最低通過票數。獲通過者一般有十票。
提名期為時一週。
解任方式為reconfirmation vote，此制度類似優特重審，即要求重新進行授權投票。

英文版目前bot applications制度如下:

bot applications 設trial period 制度。一般為50 edits。BOT從申請到正式批准需三次批核。(50 trial / 100 extended trial / approved)
通過約需一週至一個月。
只需一名BAG審議即可。

--Temp3600（留言） 2017年1月28日 (六) 09:57 (UTC)

我想先看看大家有沒有什麼想法。如果沒有的話，我可能數天後提出本地方案初稿。如果需要設立投票，希望@和平奮鬥救地球：協助處理。
請注意本案頗為複雜，涉及兩大部分:創設BAG制度，及修訂目前機器人申請方針。提出意見時，請考慮不同部分之間的互動。

--Temp3600（留言） 2017年1月28日 (六) 10:12 (UTC)

即使是在英文版BAG active members也只有7人。盡力而為吧。--Temp3600（留言） 2017年1月30日 (一) 09:36 (UTC)

分拆機器人方針

和奮球坑我啊...我要先拆出bot policy 為一獨立頁面。--Temp3600（留言） 2017年1月30日 (一) 09:47 (UTC)
弄好了第一部分-直接分拆。見草稿:Wikipedia:機器人方針。由於日後要補上機器人審核小組的有關章節，我想先看看有沒有人想借機修改機器人方針。由於本案不涉任何實質修訂，如沒有反對意見，將直接通過。

@和平奮鬥救地球、Clear Sky C、小躍、PhiLiP：--Temp3600（留言） 2017年1月30日 (一) 10:17 (UTC)
@Temp3600： 謝謝您，那麼原本的「指引」、「參見」、「資源」要改移動到何處呢？-和平、奮鬥、救地球！（留言） 2017年1月31日 (二) 03:15 (UTC)
@和平奮鬥救地球：那些可移可不移，因為BAG group設立的規定要寫進方針裏面，所以要先獨立出來。本身的機器人頁面則可按英文版再改。--Temp3600（留言） 2017年1月31日 (二) 03:50 (UTC)
OK。既然並未涉及任何實質修訂，我想如果一天內沒有任何反對意見就通過吧。-和平、奮鬥、救地球！（留言） 2017年1月31日 (二) 04:01 (UTC)
離提出已有一天，拆分完成。順帶一提，如參考英文版，「指引」部分也會移入方針區。--Temp3600（留言） 2017年1月31日 (二) 16:15 (UTC)

機器人申請頁面

日後的機器人申請頁面:草稿:維基百科:機器人/申請。有意見請提出。--Temp3600（留言） 2017年1月30日 (一) 17:07 (UTC)

草稿:Wikipedia:機器人審核小組初稿完成。請注意本文甚短，因主要內容將仿傚英文版放到方針裏。--Temp3600（留言） 2017年1月30日 (一) 17:52 (UTC)
  讚-和平、奮鬥、救地球！（留言） 2017年1月31日 (二) 03:16 (UTC)
這算是遺留問題，可一併改之。--Temp3600（留言） 2017年2月1日 (三) 17:41 (UTC)

BAG產生辦法提案

既然方針拆分完成，終於可以在方針上進一步修改了。我的初步提案如下:

申請加入BAG組規則如下:
所有行政員自動加入。
投票權限於有本地機器人的用戶。AWB使用者應否有權投票則未定。
參選權屬於所有用戶。這主要是方便一些以前有機器人，或是在外站有豐富經驗的用戶。
當選最低要求為+5票。正反票一一扺消。
投票期約一星期。社群可在期間提出問題考察申請人的能力。
提問期一星期。行政員在社群結束討論後，可關閉投票，作出決定。
半年不參與機器人事務，則標記為不活躍用戶。是否移稌出組可議。我建議暫時涷結資格，用戶回歸時只要無人反對就可開始工作。
罷免方法為信任投票，等於重選。(即目前優特重審。)冷靜期三個月。只有擁有投票權的用戶有資格提出信任投票。


日後機器人授權流程如下:

分四階段，每階段約一星期
申請測試許可(1-3 天)-第一階段測試(50edits/7-10days)-第二階段測試(100edits/7-10days)-正式通過
一名BAG就可通過，行政員可直接授權，不必再審查。所以一但批出正式許可就無法收回，只能要管理員把BOT封掉。如其他BAG對該機器人有疑慮，應及早提出。


注意: BAG組雖無正式權力，但其作為維基機器人事務的正式諮詢組織，擁有機器人事務上最大的發言權。

--Temp3600（留言） 2017年1月31日 (二) 17:02 (UTC)
(？)疑問：
  1. 「投票期」與「提問期」之差異？
  2. 「第一階段測試」與「第二階段測試」之差異？
以上。-和平、奮鬥、救地球！（留言） 2017年2月1日 (三) 04:29 (UTC)
1.這是為應對菲菇和白磷提出的「可否考慮可以將結束時間設置在最後一次有效討論之後的XX天（類似但不等同於互助客棧的存檔規則）」而設，希望給予申請人足夠的時間回答問題。
2.這個可舉例:
小明在X月1日向BAG提出申請。社群覺得其計劃不錯。7日，BAG批准第一階段測試。小明在8日開始測試，發現不少細節問題，並一一修正，在13日表示一切問題都已解決。BAG於是在14日批准第二階段測試。小明在15-18日測試，再沒有問題出現，同時社群也沒有反對意見。BAG最終在21日正式批准申請。
在「第一階段測試」發現問題是正常的，而「第二階段測試」則預期BOT已能夠正常運作，只是給予社群足夠的時間檢查是否有遺漏的錯誤。--Temp3600（留言） 2017年2月1日 (三) 10:35 (UTC)
  讚-和平、奮鬥、救地球！（留言） 2017年2月1日 (三) 11:26 (UTC)
當然，如果在第二階段發現新問題，測試階段自然需要延長，甚至重新進行第二階段測試。--Temp3600（留言） 2017年2月2日 (四) 09:11 (UTC)
沒有大的意見。只是這一條「半年不參與機器人事務，則標記為不活躍用戶」。私覺得在沒有專用日誌可以過濾的情況下，要人為判定這點似乎得付出很大工作量（得逐條檢查用戶的發言記錄）；和回收的那一點權力（實際上只是諮詢權而非執行權）相比，判定花費的人力可能不太划算。--菲菇＠維基食用菌協會 2017年2月2日 (四) 05:07 (UTC)
這一點可以再改鬆一點。不活躍標記主要是用來提示申請人可以找那些活躍用戶幫忙。我覺得"感覺"他有一段時間不活躍，對用戶頁提醒一下，如無回應就可以標成不活躍了。--Temp3600（留言） 2017年2月2日 (四) 09:11 (UTC)
誠邀@Antigng、Kanashimi、Black9869184、WilliamSkyWalk、A2093064：前來參與討論。--Temp3600（留言） 2017年2月2日 (四) 18:39 (UTC)
誠邀@Shizhao、Stang、Liangent、小躍：前來參與討論。(以上各位為本年度的BOT申請者。)--Temp3600（留言） 2017年2月2日 (四) 18:45 (UTC)
@Temp3600：要算幾天才無回應？--水中撈躍 2017年2月3日 (五) 05:46 (UTC)
@小躍：唔...兩個星期?@PhiLiP：覺得兩星期夠嗎?--Temp3600（留言） 2017年2月3日 (五) 07:45 (UTC)
足夠了。--菲菇＠維基食用菌協會 2017年2月4日 (六) 08:42 (UTC)
@Temp3600：究竟是要「涷結」？還是要「凍結」？--水中撈躍 2017年2月4日 (六) 08:58 (UTC)
這只是打錯字吧...私以為是"凍結"。--Temp3600（留言） 2017年2月4日 (六) 09:02 (UTC)
  1. 「投票期約一星期」和「提問期一星期」不妨合併。
  2. 「申請測試許可」期不需要這麼長，個人認為3天就行。
  3. 這個投票建議參考監管員的選舉，即提問期在投票器以前開始，如果提案人「希望給予申請人足夠的時間回答問題」的話。以上。-- Stang 124 2017年2月5日 (日) 01:19 (UTC)
  1. 投票期和問答期是同時開始的，只是問答期比投票期更早完結。如果想改成問答期比投票期早一點開始也可以。
  2. 翻查英文版，「申請測試許可」期常只有一天，故同意縮短。--Temp3600（留言） 2017年2月5日 (日) 10:13 (UTC)
四個階段只是建議/常規流程吧？從目前申請的bot案例看，大多數都不必第二階段測試--百無一用是書生 (☎) 2017年2月17日 (五) 03:53 (UTC)
如果機器人在第一階段測試時沒有任何出錯，自然可跳過第二階段測試。--Temp3600（留言） 2017年2月17日 (五) 06:22 (UTC)

投票權認定

對AWB用戶(在checkpage有名字的用戶)，可以讓他們投半票。投票通過票數維持五票。大家意下如何?--Temp3600（留言） 2017年2月2日 (四) 09:13 (UTC)

「管理員如要使用AWB，可將自己的用戶名列入」。這是否意味著管理員都可以投半票？-- Stang 127 2017年2月2日 (四) 10:12 (UTC)
技術上而言，是。我只能希望管理員能自律，只在確實熟悉AWB的情況下才投票。--Temp3600（留言） 2017年2月2日 (四) 13:52 (UTC)
個人覺得不是AWB問題，而是bag的人選是否對信息技術和編程有一定的了解。所以我的粗淺看法是滿足兩條即可：1.對信息技術和編程有一定的了解；2. 對方針指引比較了解。--百無一用是書生 (☎) 2017年2月3日 (五) 03:10 (UTC)
@Shizhao：社群中任何編者都可以參選bag，然而，我希望獲選的BAG得到本地機器人社群的認可，所以在投票權加上了限制。--Temp3600（留言） 2017年2月3日 (五) 07:40 (UTC)
BAG由行政員審核如何？投票只用於表達意見而不用於計算票數。 --達師 - 345 - 574 2017年2月5日 (日) 10:04 (UTC)
這樣會大幅降低BAG的認受性啊...我相信獲得本地機器人社群的認可是BAG的條件之一。--Temp3600（留言） 2017年2月5日 (日) 15:57 (UTC)
我是指類似於存廢討論的安排。不拘泥於票數而只考慮共識的達成。 --達師 - 345 - 574 2017年2月6日 (一) 17:49 (UTC)
類似於現在GR，GS產生方式。-- Stang 122 2017年2月7日 (二) 01:18 (UTC)
那將最低支持票改為最低討論參與人數如何?--Temp3600（留言） 2017年2月7日 (二) 05:14 (UTC)
也可以。--William is Wikipedia! 2017年2月7日 (二) 08:44 (UTC)

正式提案

草稿:Wikipedia:機器人方針已經翻譯完畢。中文現行方針已合併到相應的章節，而過時的部分則順便取消。上面討論的審核小組產生辦法尚未加進去－我在想應放到那兒。本版本主要供各位檢查有否重大錯誤之處。--Temp3600（留言） 2017年2月7日 (二) 20:49 (UTC)

放了到WP:BAG--Temp3600（留言） 2017年2月14日 (二) 06:46 (UTC)
本更新除設立BAG外，亦包括以下修改:
新增部分:

1.明確定義機器人、半自動編輯、腳本
2.要求機器人以assertion功能防止未登入時編輯

solved
這個為何是必須的？--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)
防止未登入時編輯。我留意到assertion extension已加入mediawiki中，如果中文版沒有此問題可取消本條。 --Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)
(－)反對，我有無數種方法防止未登錄編輯，比如當token="+\"的時候立即終止進程，根本沒有強制assertion的必要。--Antigng（留言） 2017年2月8日 (三) 14:33 (UTC)
雖然我現在也在用assertion，但還是(－)反對這條，沒必要限制具體的實現方法。(＆)建議改成推薦。 --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 14:46 (UTC)
再舉個例子，封禁User:10.68.0.0/16（目前已經被封禁）即可阻止Tool Labs的機器人未登入編輯，用不著這麼囉嗦。--逆襲的天邪鬼（留言） 2017年2月8日 (三) 14:50 (UTC)

3.要求機器人輸出的訊息(如編輯摘要)能被普通用戶明白，及要以禮貌語氣書寫
4.要求機器人在用戶頁列出工作項目、自動化程度、頻率
5.不容許製作以大量下載維基為目的的機器人

(－)反對，這要求有道理但是沒有意義，因為只要帳戶不往維基百科裡寫東西，就算他大量下載內容也沒有人能發現，管理。就算把這個帳戶封禁了他也照樣能大量下載內容。--Antigng（留言） 2017年2月8日 (三) 14:49 (UTC)
不需要提——如果我不希望讓你們知道我在通過Bot下載東西的話，我甚至根本不需要註冊帳號。--逆襲的天邪鬼（留言） 2017年2月8日 (三) 14:50 (UTC)
原文為"Bots that download substantial portions of Wikipedia's content by requesting many individual pages are not permitted. "我可能譯錯了，重點是在取得內容的方法，讓我想想怎改... --Temp3600（留言） 2017年2月8日 (三) 16:40 (UTC)
見2009年的方針：「bot不能用於與獲得批准的bot任務無關的，大量資料的傳送。這包括從其他網站動態載入內容，這將導致網站被列入黑名單，並且bot帳號被永久查封。如果你想大量下載內容或鏡像這個站點，請從我們的資料庫下載。」經過2013年的討論，這些內容被刪掉了。--Antigng（留言） 2017年2月8日 (三) 16:58 (UTC)
可是13年的討論也沒有明確反對這一條啊，而且留著也沒有壞處。--Temp3600（留言） 2017年2月9日 (四) 11:17 (UTC)

6.在用戶討論頁發放訊息的機器人應設有拒絕訊息機制

solved
這個在中文版是否已經有完善機制？是否強制？--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)
至少要設有黑名單。如果有人直接找操作者要求停止發訊，我覺得應予尊重。--Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)
順便加一個：可以給機器人加入緊急停止功能，但不是必須要加。--逆襲的天邪鬼（留言） 2017年2月8日 (三) 15:01 (UTC)
這是強制要求。--Temp3600（留言） 2017年2月8日 (三) 16:40 (UTC)原文是may...--Temp3600（留言） 2017年2月9日 (四) 10:59 (UTC)
(？)疑問：我沒看到現在的draft里哪有強制要求加入緊急停止功能……管理員緊急封禁這個算嗎？ --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 17:28 (UTC)
這次提案有數份文件。Draft:維基百科:機器人/申請see here --Temp3600（留言） 2017年2月8日 (三) 17:33 (UTC)
嗯嗯了解，那就是要加入{{Emergency-bot-shutoff}}吧，現在的機器人好像都有。 --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 19:49 (UTC)
(－)反對強制，不管怎樣，都可以直接封禁掉。封禁本身就是緊急停止功能。沒必要非得加入一個模板。模板只是更顯眼而已，可以推薦使用，但沒必要強制--百無一用是書生 (☎) 2017年2月9日 (四) 06:47 (UTC)
譯錯，會改。--Temp3600（留言） 2017年2月9日 (四) 10:59 (UTC)

7.機器人應留意{{inuse}}模版機器人應避免編輯衝突

solved
如果目的是防止編輯衝突，單單是{{inuse}}沒有大多意義--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)
可否解釋? --Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)
就是說防止編輯衝突不是單單靠{{inuse}}來解決的。只要bot具有防止編輯衝突的機制就可以了--百無一用是書生 (☎) 2017年2月8日 (三) 09:40 (UTC)
(－)反對，同上，防止編輯衝突檢查timestamp即可實現。--Antigng（留言） 2017年2月8日 (三) 14:39 (UTC)
(－)反對，有些條目的inuse掛了幾個月都沒人理。--逆襲的天邪鬼（留言） 2017年2月8日 (三) 14:51 (UTC)

8.規定以自動或半自動方式批量創建條目前必須申請

seems solved
現在中文維基百科似乎是根本不允許批量創建條目，請仔細檢查相應的討論與共識，在完成確認之前(－)反對。--Antigng（留言） 2017年2月8日 (三) 14:39 (UTC)
見Wikipedia:互助客棧/其他/存檔/2013年2月#模板容量上限現況疑問、Wikipedia:頁面存廢討論/記錄/2013/02/18#天河公園站--Temp3600（留言） 2017年2月8日 (三) 16:50 (UTC)

9.正規化申請上訴/除權程序
10.收緊對adminbot的規定，BAG及管理員有權要求adminbot交出原始碼。adminbot必須得到社群的廣泛認可才可執行。(i.e. 乏人問津的adminbot申請會失敗)

seems solved
必須交出源碼有點過分？但是應該強烈建議對所有的bot使用的工具代碼開源（尤其運行在labs上的bot，見wikitech:Nova Resource:Tools/Rules）。此外，強制交出原始碼在務實上也可能存在困難，比如只是處理任務當中的臨時性腳本，隨手寫的，用完一次就不再用了；比如過程中用到的shell腳本，公開有可能涉及伺服器安全；比如使用的第三方現成的閉源工具--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)
這條只限制adminbot。如果adminbot出錯影響很大。而且本條是指BAG有權要求交出原始碼，如果BAG認為不需要這樣檢查，自然可以不交。--Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)
(－)反對，例如尋找開放代理等執行有風險任務的bot不應該（任何人要求都不可以）讓任何人知道原始碼。--Antigng（留言） 2017年2月8日 (三) 14:29 (UTC)
我無法明白。BAG在為受社群信任的維基人，有權知道一切 - 當然，如果BAG接受你的解釋的話，可以不查。如果你那麼不願意信任他人的話，為什麼你要去寫維基呢?--Temp3600（留言） 2017年2月8日 (三) 16:53 (UTC)
如果公布原始碼，我這個喜歡破壞維基百科的用戶就可以簡單地改改源碼，做到既能用開放代理實施破壞，又不會被發現而招致封禁了。所以不是不信任的問題，而是現在有人在互助客棧方針版威脅你們。（正經話：製造者應該有權不公開原始碼，或者僅限於內部傳閱，甚至不對任何人公開。adminbot的製造者應該清楚濫用信任的後果。）--逆襲的天邪鬼（留言） 2017年2月9日 (四) 15:43 (UTC)
adminbot出錯的危害太大，本條的code review權力對此十分重要。連反破壞王牌cluebot都有公開原代碼，我想不到中文維基有什麼黑科技，一公開就見光死。另外，BAG是得到社群信任的用戶。如果adminbot申請人不信任BAG，他就不應該申請機器人了。--Temp3600（留言） 2017年2月9日 (四) 19:46 (UTC)
記得en有個封禁開放代理的adminbot由於安全問題不予開源。-- Stang 121 2017年2月8日 (三) 07:24 (UTC)
同樣，如果bag同意不需交出原始碼，自然可以不交。交原始碼給bag不等於開源 - bag只可以內部傳閱原始碼。--Temp3600（留言） 2017年2月8日 (三) 07:39 (UTC)
認可。不過希望「有權要求交出原始碼」改的口氣較為柔和。-- Stang 121 2017年2月8日 (三) 07:43 (UTC)
"It is recommended that the source code for adminbots be open, but should the operator elect not to do so, they must present it for review upon request from any BAG member or administrator."原文用了must，我在想應怎樣翻譯較好。--Temp3600（留言） 2017年2月8日 (三) 10:42 (UTC)
直譯成「若小組成員要求，必須……」呢？或者試試 RFC 6919 的 "MUST (BUT WE KNOW YOU WON'T)" 吧。[開玩笑的]——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月8日 (三) 13:06 (UTC)
改了一點，請看看。 --Temp3600（留言） 2017年2月8日 (三) 14:30 (UTC)
可以更柔化一些，「有權要求審閱原始碼」。這裡的重點是用code review來確保代碼安全，不是確保代碼可分享。--菲菇＠維基食用菌協會 2017年2月9日 (四) 16:06 (UTC)
謝謝菲菇，已改。--Temp3600（留言） 2017年2月9日 (四) 19:37 (UTC)

11.容許自願辭職的管理員在社群請求下保留adminbot權限離任管理員可將adminbot轉交給其他管理員，讓其他管珼員保持該機器人的運作

solved
結合上一條，這種要求表現出來的樣子，似乎讓人感到我們過於依賴bot了。這樣可能會有很大的隱患。人的工作被bot限制住了，沒了bot難道就做不了事情了？--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)
這條發動的機會同樣十分低。但如果一名受信任用戶因私人理由辭職而要求adminbot退役，是社群的損失。--Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)
(－)反對，安全隱患。不過完全可以由另外一個有資格運行adminbot的人運行（即所有權轉交）。-- Stang 121 2017年2月8日 (三) 07:46 (UTC)
好吧，如果再有其他人反對這項，我就把它取消掉。--Temp3600（留言） 2017年2月8日 (三) 10:32 (UTC)
同意轉交的方案。 --達師 - 345 - 574 2017年2月12日 (日) 10:26 (UTC)
OK，已改。--Temp3600（留言） 2017年2月14日 (二) 06:35 (UTC)

12.對多人共用的機器人作出規定
13.新增活躍度要求:如機器人及操作者兩年沒有編輯，機器人會被除權。設有一星期的通知期。

seems solved
Wikipedia_talk:機器人#.E8.AE.BE.E7.AB.8B.E6.9C.BA.E5.99.A8.E4.BA.BA.E9.99.A4.E6.9D.83.E6.9C.BA.E5.88.B6。-- Stang 121 2017年2月8日 (三) 07:26 (UTC)
@Stang：看了討論，但仍不明白情況如何麻煩。請指教。 --Temp3600（留言） 2017年2月8日 (三) 07:31 (UTC)
「一大堆iwbot的操作者都不在本地，應該不需要擴展到全域編輯數吧？--Jimmy Xu 論 2016年5月13日 (五) 16:08 (UTC)」。另未收到提及。-- Stang 121 2017年2月8日 (三) 07:39 (UTC)
另，應opt-out掉系統帳戶。-- Stang 121 2017年2月8日 (三) 07:42 (UTC)
取消部分:
  1. 容許就所有任務申請adminbot，但須有廣泛共識
  2. 取消向監管員要求授權的安排。除global bot外都需經bag審批

--Temp3600（留言） 2017年2月8日 (三) 04:20 (UTC)

討論

(為方便討論，我可能移動你的留言。如果你反對的話，請告訴我。)--Temp3600（留言） 2017年2月8日 (三) 10:23 (UTC)

inuse, adminbot code review
seems solved
  • (？)疑問：
    • 「機器人應留意{{inuse}}模版」，怎麼「留意」呢，永遠不編輯帶inuse的頁面嗎？另外現在的API有兩個參數是開始編輯的時間戳和編輯時上一版本的時間戳，這兩個參數填對就能防止衝突，所以好像沒什麼必要特別留意inuse模版？如果要防編輯衝突，可以要求機器人的編輯均需加上那兩個參數，討論頁新開話題除外（因為永遠不會衝突）。
    • 「如果機器人依賴一些不公開的規則來運行（如利用一連串正則表達式來決定行動），審核小組組員及管理員有權要求機器人操作者提供該等規則供審閱。」正則表達式為什麼是不公開的規則……按我的理解是不是要把正則表達式的匹配規則用白話解釋給BAG和管理員？
    • 交出原始碼的問題，例如A要求後向他交出了代碼，如果後來這代碼經過了或大或小的修改，是否必須要向A重新發送？
  • 以上。 --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 04:57 (UTC)
    • 原文為「If the bot operates upon additional rules (such as lists of regular expressions applied in a particular decision-making process) that are not publicly visible, the bot operator should make these available to any BAG member or administrator upon request」。因此「不公開的額外規則」指的應是正則表達式等規則本身沒有公開的情況。——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月8日 (三) 05:01 (UTC)
(：)回應留意{{inuse}}模版指如機器人發現有2小時內掛的inuse模版，不應作任何編輯，以避免編輯衝突
Artoria2e5已解釋「不公開的額外規則」。這是確保機器人運行時所有有關代碼都得到審閱，不能弄黑盒。
白磷是指申請期間修改還是申請成功後再作修改?
--Temp3600（留言） 2017年2月8日 (三) 05:08 (UTC)
註：目前按照 sec 3.1.1 "在不經批准下合法運行的條件" 處理的話，小修改應不需要交出。我的建議是建議adminbot用戶主動提交，同時允許小組成員做出明示的「每次都提交」要求。提交最好包含歷史。——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月8日 (三) 05:15 (UTC)
小修改可不用交出，除非BAG明文要求。至於具體個案的提交形式，我覺得可由BAG自行決定。 --Temp3600（留言） 2017年2月8日 (三) 09:13 (UTC)
但是是不是可以假設「使用完畢或暫時不再編輯時」，加入模版者會「刪除這個標籤」，所以可以直接看到inuse的頁面就不管。 --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 05:21 (UTC)
嗯嗯，這依靠掛inuse的用戶自律了。--Temp3600（留言） 2017年2月8日 (三) 09:15 (UTC)
弄個機器人去維護啊，Category:被擱置的條目。--A2093064#Talk 2017年2月8日 (三) 12:48 (UTC)
有些條目的inuse掛幾個月都沒人理，所以不能指望用戶自律。--逆襲的天邪鬼（留言） 2017年2月8日 (三) 14:54 (UTC)
嗯嗯，總之我還是(－)反對這個，如我所述用timestamp判斷就行，後者是這個的超集。 --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 14:58 (UTC)
嗚，我認錯。為什麼有那麼多人喜歡亂掛inuse啊...--Temp3600（留言） 2017年2月8日 (三) 17:01 (UTC)
（跑題）因為很容易忘記拿掉嘛……如果規定忘記拿掉的人會被自動永久封禁，肯定就沒人用這模板了。[開玩笑的] --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 17:35 (UTC)
    • 我認為代碼修改的覆核，沒必要每次都覆核，除非代碼修改導致與原來所申請的任務有很大的不同才可能有必要覆核（有時候可能已經都變成了一個新任務了）。這個不應該規定太嚴格，可以寬鬆一些，如何判斷交由BAG來處理。另外我認為不需要提交代碼給誰，鼓勵代碼開源就足夠了（在半自動編輯指引章節，也有說「與機器人一樣，我們鼓勵，但不強逼創造者公開工具的原始碼。」）--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)
      • 我認為需要多嚴格的CODE REVIEW應由BAG需決定。但BAG應保留權力，在必要時審閱adminbot的代碼。只有adminbot才有這項額外規定，可算是為防萬一的措施。--Temp3600（留言） 2017年2月8日 (三) 09:38 (UTC)
bot max speed
solved

No objection. The six per minute rule is already ignored in many cases anyway. I would suggest though that fast should not be the default bot rate, but rather than bots be allowed to push the speed limit only if there is an argument for why faster editing is useful. For example, bots that response to user actions (e.g. antivandal) might be able to do more (assuming any of them are in fact obeying a 10 second rule right now), but on the other hand things like adding dates to tags can be completed at a leisurely pace, since it doesn't really matter if the run takes 10 hours or 2. And if there should be a problem, slower is still better. So, yes higher speed seems fine, when necessary/useful. Dragons flight 19:22, 21 February 2007 (UTC)

The intent of restricting edit speed is a.) so as not to overload the servers, which isn't as much of a concern now that the maxlag parameter exists and is (I believe) used by AWB, and b.) if there might be any possible problem with the task, so it can be caught in time to stop and revert before too much damage is done. 3-4 edits a minute is a restriction, in my opinion, beyond the bot policy's remit. If you're making semi-automated edits, just make sure you're checking all of them and you're fine. That being said, AWB's restrictions may be more stringent than those of the bot policy so if your question is specific to them you should ask at WT:AWB or the like. Cheers, — madman 04:34, 17 September 2012 (UTC)

@Antigng：可以看看英文版為何立下這條規定。 --Temp3600（留言） 2017年2月8日 (三) 17:16 (UTC)
第二段主要針對AWB？ --碸中嘌呤的白磷萃取 打譜 2017年2月8日 (三) 19:53 (UTC)
@WhitePhosphorus：你讀壞了。第一個人是說必要的時候可以申請加速，但是大部分事情都沒那麼急。第二個人列出了當時這麼做的兩個理由：一是之前提到的伺服器性能原因，現在已經不是問題（AWB等程序可以測量卡頓）；二是出錯了來得及停下。——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月9日 (四) 00:38 (UTC)
嗯嗯，熬夜熬傻了。 --碸中嘌呤的白磷萃取 打譜 2017年2月9日 (四) 02:26 (UTC)
@Temp3600：，這些只能證明為什麼bot需要一個速率上限。然而為什麼這個上限是0.2req/s則完全沒有論證。以我自己的bot為例，現在在過濾器的限制下速率上限是1req/s，我也沒有發覺有任何問題。而且一旦bot出故障，這個速率限制已經能夠攔下絕大多數的問題編輯了，見過濾器日誌。--Antigng（留言） 2017年2月9日 (四) 01:04 (UTC)
@Antigng：這多少是原則問題了。你認同英文方針中「The urgency of a task should always be considered; tasks that do not need to be completed quickly (for example, renaming categories) can and should be accomplished at a slower rate than those that do (for example, reverting vandalism).」一句嗎?--Temp3600（留言） 2017年2月9日 (四) 03:54 (UTC)
這是很顯然的，根據常識也可以知道。比如Cluebot的速率上限是9000req/min。--Antigng（留言） 2017年2月9日 (四) 04:01 (UTC)
見Wikipedia_talk:機器人#.E6.93.8D.E4.BD.9C.E9.A2.91.E7.8E.87：「現有的WP:機器人#節約資源一段已經嚴重過時，那些限制顯然太高了，對於機器人的編輯頻率，應當不作出強制限制。如果的確影響到了伺服器的性能，我相信系統管理員會聯繫相關用戶，或直接作出相應的處理。對於未獲得權限的帳戶（如試運行期），大量編輯限制在1分鐘5次如何（當然如果只是一小部分的編輯，比如只改十來個頁面，可以不必限制）？」--Antigng（留言） 2017年2月9日 (四) 04:07 (UTC)
這是程度的問題。為了遵從比例原則，那些不緊急的項目應如何"慢"呢? --Temp3600（留言） 2017年2月9日 (四) 04:12 (UTC)
所謂慢不應該是「為慢而慢」，快也不應當是為快而快，而是要綜合考慮伺服器的承載能力和任務的易錯程度以後再判斷應當使用何種速度。容易錯的任務，比如創建重定向，可能出錯需要人查，縮小較大的圖片，可能把長截圖縮成棍子，也需要人檢查。這種情況下，就算1分鐘1個，24小時不間斷就是1440個，人也查不過來，還是快。然而批量移除已刪模板，在處理之前查一下鏈入頁面就可以保證沒有錯，就算1分鐘跑完100個頁面也不嫌快。一刀切地上限0.2req/s沒有道理。--Antigng（留言） 2017年2月9日 (四) 04:20 (UTC)
要是如此，只好將決定權交給BAG逐案判斷了。--Temp3600（留言） 2017年2月9日 (四) 11:02 (UTC)
@Antigng：但是我總得寫個一般參考值... --Temp3600（留言） 2017年2月9日 (四) 11:07 (UTC)
如果沒有從技術角度來論述為什麼是「應該是xx req/s」，那麼最好不要寫具體數值，只留一些模糊的語句（例如「編輯頻率要綜合考慮伺服器的承載能力和任務的易錯程度」），以免留下「外行指揮內行」的印象。--逆襲的天邪鬼（留言） 2017年2月9日 (四) 16:02 (UTC)
好吧，改了。BAG判斷吧。--Temp3600（留言） 2017年2月9日 (四) 19:54 (UTC)
文辭修正
solved

「在過往，批核過程和獲得機器人權限是分開的；並不是所有獲批的機器人都有權限。這是由於有些機器人的編輯不應從最近更改中隱藏。現在由於用戶可選擇在最近更改顯示機器人編輯，這情況已不再出現。」一直沒太明白說這個的原因是什麼？無論en，還是c區，直到現在仍然有很多未獲bot權限的bot。尤其是C區，大部分用來上傳的bot都沒有bot權限。有時不僅僅是「有些機器人的編輯不應從最近更改中隱藏」，而是希望有更多的人看到bot的編輯（例如大部分上傳bot，希望能有人類編輯來給它上傳的文件進行進一步整理；例如User:CommonsDelinker，希望人類能發現到被錯誤刪除或替換的圖像；例如User:RonaldB，希望能有更多用戶看到OPD的更新）--百無一用是書生 (☎) 2017年2月8日 (三) 07:12 (UTC)

現在本地還存在沒有bot flag的機器人嗎? --Temp3600（留言） 2017年2月8日 (三) 09:54 (UTC)
上面列的兩個都是啊。-百無一用是書生 (☎) 2017年2月8日 (三) 15:30 (UTC)
這個有點麻煩，讓我想想--Temp3600（留言） 2017年2月8日 (三) 17:49 (UTC)
"現在由於用戶能在最近更改顯示機器人編輯，一般獲準的機器人都會獲得權限，除非申請者主動表示不要權限。」如何? --Temp3600（留言） 2017年2月9日 (四) 05:14 (UT
這點當然如此。BAG只是有權內部傳閱adminbot的代碼作審核之用，而非對外發佈。可能弄個private repositories吧--Temp3600（留言） 2017年2月9日 (四) 11:11 (UTC)
用戶在機器人申請書中，可標明自己不需要機器人權限。--Temp3600（留言） 2017年2月9日 (四) 11:13 (UTC)
bag應該可以根據情況，靈活判斷需不需要給bot權限，即使用戶標明自己不需要機器人權限，bag也應該有權要求用戶必須有blog權限--百無一用是書生 (☎) 2017年2月9日 (四) 12:07 (UTC)
同意，已改--Temp3600（留言） 2017年2月9日 (四) 19:59 (UTC)
不服重審
solved

@Temp3600：原方針中說：「在經過一段時間的討論後，行政員將根據社群共識批准或拒絕申請。對於已拒絕的申請，申請者仍然可以陳述自己的觀點，要求作出決定的行政員或其他行政員重新考慮授權，或重新提出新的申請。但在社群共識明顯的情況下，申請者應該避免擾亂性的申訴。」請問在實行BAG後，如申請者不服，如何請求重審？-- Stang 119 2017年2月10日 (五) 04:10 (UTC)

用戶可於Wikipedia:機器人/申請#申請覆核提出，由另一位BAG成員複檢。如果情況特殊，可能需要社群全體的參與。--Temp3600（留言） 2017年2月10日 (五) 04:44 (UTC)
幾個小問題
  1. 「然而，如果操作者能證明機器人不會出錯（如將所有要修改的項目先試運行一次）」，何謂「所有要修改的項目先試運行一次」？所有要修改的項目都跑完一遍了也不用申請了，因為都改好了:P
  2. 「跨語言連結機器人應停止運行」，是否需要明確定義何謂「跨語言連結機器人」以避免爭議？
  3. 「更簡單的方法是逐少創建條目，或先在各屬專題的子頁面創建條目，由其他編輯檢查後，再移動到條目空間。這些方法不用申請機器人，也更容易得到社群的支持」，如果是條目「先在各屬專題的子頁面創建」的批量創建，還是會造成最近更改的洗版吧？那Draft呢？
  4. 「如機器人帳號及其操作者最近兩年沒有編輯」，是「且」的意思嘛？
  5. 「所有行政員都自動成為小組的一員」，那麼有無需要名列成員名單中？或者給個連結就好？

以上。希望能釐清一下規則以避免日後可能的爭議。-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月16日 (四) 09:01 (UTC)

「試運行」指在自己的用戶子頁模擬運行所有修改一次。社群不容許機器人未獲得許可時直接在條目頁面運行，所以「所有要修改的項目都跑完一遍了也不用申請了，因為都改好了」並不會出現-根本連測試許可都不會批出，這類工作直接拒絕之。
可略改為目前方針中「維護跨語言連結的機器人」，並加上到Help:跨語言連結的連接。
「先在各屬專題的子頁面創建」頁面的確會洗版，正如在用戶子頁批量創建一樣。但批量創建無可避免會洗RC，在專題洗已是較容易管控的方法。Draft不方便條目的集中管理。而且本條希望批量創建者能得到專題的同意和幫助，儘力保證該批條目的質量。
「如機器人帳號及其操作者最近兩年沒有編輯」is both bot account and its operators.
我沒有所謂。為方便管理，可不列入，僅給連結。
--Temp3600（留言） 2017年2月16日 (四) 09:34 (UTC)
  1. 跨語言連結部分，應否排除「出現在正文中的連結」部分，因為那應和本條立意無涉。
  2. 「本條希望批量創建者能得到專題的同意和幫助」，如何定義「得到專題的同意」？畢竟本地目前很多專題都只有1,2個人在維護、甚至沒有活躍者。很多也無法明確定義「專題成員」。-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月16日 (四) 10:01 (UTC)
第一項位置不明，請給出上下文。第二項採半強制性質-如果您覺得專題無用，也可以在自己的用戶子頁進行，但我相信有關的專題編輯已經是最可能有意願協助檢查條目的人了。「得到專題的同意」指部分該類條目的編者可能反對批量創建，如果無法取得他們的同意，應停止批量創建。--Temp3600（留言） 2017年2月16日 (四) 10:09 (UTC)
第一項位於Help:跨語言連結。第二項的部分，技術上BAG成員如何確認有關的專題編輯同意與否？-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月16日 (四) 10:13 (UTC)
跨語言連結機器人指的是interwikibot，至少在wiki的英文語境下沒有歧義。個人認為批量創建至少應該申請bot任務批准後才運行（至於是否要bot flag則視情況而定）。「如將所有要修改的項目先試運行一次」這只是舉例吧？並不是所有的任務都能全都先試跑一遍的，甚至有的任務並無跑一遍這種概念。而且基於軟體工程自身的基本特點，誰也無法保證機器人不會出錯--百無一用是書生 (☎) 2017年2月17日 (五) 04:13 (UTC)
第一項，我並不可能為了機器人而修改Help:跨語言連結-那頁面為非為機器人事務而設。第二項，證明自己的機器人任務得到社群支持的責任在於申請者。提案者可附上專題的討論頁面連結，方便審核小組判斷。如將所有要修改的項目先試運行一次」是針對上下文修改很可能出錯，而增設的特殊規則。--Temp3600（留言） 2017年2月17日 (五) 06:17 (UTC)
並非修改Help:跨語言連結，而是在機器人方針說明清楚。例如說可以將「除非該工作無法在維基數據上進行（如連結到某一分段）」這句寫清楚成「除非該工作無法在維基數據上進行（如連結到某一分段、以及出現在正文中的連結）」-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月17日 (五) 06:41 (UTC)
唔...有機器人是在處理正文中的跨語言連結嗎?--Temp3600（留言） 2017年2月17日 (五) 10:54 (UTC)
有。例如User:Cewbot。-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月18日 (六) 10:47 (UTC)
OK，已改。--Temp3600（留言） 2017年2月19日 (日) 05:14 (UTC)
  讚-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月19日 (日) 05:27 (UTC)

提案通過

最近數天已無討論。如果社群沒有新意見，我在此提出:

統一通過草稿:維基百科:機器人/申請、草稿:Wikipedia:機器人審核小組、草稿:Wikipedia:機器人方針及其附帶文件。

七天之內如無反對意見，視作正式通過。 --Temp3600（留言） 2017年2月14日 (二) 10:36 (UTC)

我實在不懂地區轉換，如有需要，望請其他用戶協助。--Temp3600（留言） 2017年2月15日 (三) 06:42 (UTC)
就我這裡的觀察來看，應該已經有全局轉換了，不需要額外增加轉換。倒是掛上G1=IT可能有點用。 --達師 - 345 - 574 2017年2月16日 (四) 10:19 (UTC)
哈哈，加了過後「當機」被轉成「死機」於是zh-cn下傲嬌地顯示成了「死机械人」……（已修復）—菲菇＠維基食用菌協會 2017年2月19日 (日) 01:31 (UTC)
thx for your help.--Temp3600（留言） 2017年2月19日 (日) 13:04 (UTC)

修訂機器人方針，增加使用https的建議

最新留言：7 年前4則留言3個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年3月3日 (五) 08:42 (UTC)。


維基百科的機器人帳號可能用於持續、大量編輯，理應比普通帳號獲得更多安全保證，在登錄憑據被盜時做出的封禁處理也應加速執行。HTTPS是廣泛使用的傳輸層加密手段，WMF於2015年6月中旬開始強制執行HTTPS，對於普通HTTP網頁訪問執行跳轉。然而現時一些用戶（好吧，User:Antigng）使用的機器人程序仍然全局使用未經加密的HTTP，甚至通過X-Forwarded-Proto:https繞過跳轉，這幾乎是在玩火。（好在Antigng似乎是在wmflab上運行這東西，暫時沒有什麼有人搞鬼的擔憂。）

基於以上考慮，我提議在2.1「機器人帳號」一章加入以下段落：

機器人操作者有責任通過各種手段保證機器人帳號的安全。操作者應及時報告疑似被盜情況，並使用HTTPS加密API登錄、操作。

——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月21日 (二) 02:38 (UTC)

去年6月wmf把我利用的這個漏洞補上了，所以我早就不在wmflabs上使用明文HTTP工作了。現在我的bot在本地，通過正向代理將HTTP請求轉為HTTPS以後發送給wmf的伺服器。--Antigng（留言） 2017年2月21日 (二) 04:42 (UTC)
考慮到可能有人想得出跨著大老遠用 HTTP 代理，先繼續留著HTTP這條吧……（我下一個想玩的是 malformed html/template，或者 buffer overrun）——Artoria2e5編 保持討論完整，直接ping我回復。 2017年2月21日 (二) 07:45 (UTC)

機器人與自動駕駛

最新留言：7 年前10則留言8個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年6月29日 (四) 08:42 (UTC)。

最近維基百科上出現多次維基人操作的機器人出問題而無回應的情況，提報多日，均未解決。事故機器人的兩位操作者皆為不活躍的維基人。有些問題（例如誤將WP:關注度/提報當作編輯站提報的）可以手動回退，有些問題（例如出錯大量合理使用圖片）被用過濾器解決，還有些問題（Adminbot 未經機器人授權封禁代理 IP）普通用戶則無法動手修復；需要人力去回退和寫過濾器為機器人擦屁股本末倒置，失去一開始使用機器人的理由。

上述問題有部分已經被發現好一段時間。若普通用戶長時間進行非建設性貢獻，多半早已被封禁。目前因為機器人有其他貢獻無法對其進行封禁，但私以為因為用戶有重大貢獻而採用雙重標準，是不合適的行為。

機器人方針不要求操作者開放與授權原始碼，所以無法直接請懂技術的人接替不活躍操作者的機器人。既然現在已有依賴機器人又聯繫不上操作者的情況，是否應該修改機器人方針，以避免日後有更多架機長休克仍在駕駛的飛機？Dargaseat ‧ c ‧ s 2017年6月17日 (六) 08:31 (UTC)

說起來倒是有一個方法可以緩解這個問題，就是不同任務分成不同帳號編輯，方便封禁和回退。如果是一個帳號，最好能提供每個任務單獨的開關。 --碸中嘌呤的白磷萃取 打譜 2017年6月17日 (六) 13:23 (UTC)
可以用濫用日誌作出控制，無需用到封禁的程度，封禁不是為了懲罰，除非用了濫用日誌，而錯誤的編輯還是一直出錯，則予以暫時封禁以作處理。--小躍（撈出記錄） 2017年6月17日 (六) 14:22 (UTC)
Jimmy-abot和Liangent-bot雖然看起來出錯多，但依總貢獻比例來算很低，絕大多數的編輯還是有利的，支持編輯不同開分操作，甚至編輯長期不再時授權原始碼。--Zest 2017年6月17日 (六) 14:29 (UTC)
@小躍：我倒是想說沖刷濫用過濾器日誌的問題。--A2093064#Talk 2017年6月17日 (六) 15:35 (UTC)
@蘭斯特：否定貢獻比例說法，應依照每個任務各自計算錯誤率，做個誇張的比喻，假設我有1000個任務，其中一個任務錯誤率100%，這樣能被接受嗎？--A2093064#Talk 2017年6月17日 (六) 15:35 (UTC)
我的意見是指像Liangent-bot的重定向，少數會出錯，大致上沒問題，至於其中一個任務錯誤率100%，就有問題，所以支持編輯不同開分操作，以便管理。--Zest 2017年6月17日 (六) 16:06 (UTC)
如果你的意思是"A-bot必須開源"，我倒是十分贊成，不過估計通不過就是了...--Temp3600（留言） 2017年6月17日 (六) 18:09 (UTC)
如果編輯過於頻繁，AF是會宕掉的--百無一用是書生 (☎) 2017年6月19日 (一) 02:04 (UTC)

修改機器人方針

最新留言：7 年前10則留言6個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年8月28日 (一) 08:42 (UTC)。

此增修內容原為逆襲的天邪鬼於2017年2月22日（43316532、43316612、43316635、43316697、43316814、43319208）及2017年4月25日（44122868、45318362、44123011）逕自追加，嗣後經編輯者本人主動於2017年7月22日撤回「破壞」（45318362、45318349）；然查該修正內容確符中文維基百科習慣且技術上較為可行，故提案修改本（機器人）方針。

現行方針請參照本方針頁，而修改草稿請參照本草稿頁。由於修改篇幅較大，相關變更內容請參照本比較頁，歡迎提出意見。--小火車（留言） 2017年7月28日 (五) 22:03 (UTC)

有種故意習慣成自然的問題，利用沒人注意到的可能修改方針，然後過足夠長時間被發現的話，可以按照以長久實行無不妥為默許而通過修訂。——路過圍觀的Sakamotosan 2017年7月30日 (日) 01:08 (UTC)
如果真有這種事我又幹嘛提出這個修正案？--小火車（留言） 2017年7月31日 (一) 12:19 (UTC)
你說的沒錯，User:Temp3600不懂裝懂，我篡改方針，反正結果都是損毀性的。如果說有什麼區別，我的修改用一個撤銷按鈕就恢復了，而他的修改卻不能一個撤銷搞定。沒關係，反正你們的修訂都是通過討論得出的共識，對就是對，錯也是對，敢和社群對著幹的都是損毀性編輯。我知道你們最擅長打仗，你們隨便，我不跟你們玩，只要我不參與你們能拿我怎麼樣。--逆襲的天邪鬼（留言） 2017年7月30日 (日) 11:46 (UTC)
所以偷偷改方針是非常麻煩危險的事，天邪鬼別整天搞這種貪得意的無聊行為，既然發現了並取消了，就算了。——路過圍觀的Sakamotosan 2017年7月31日 (一) 01:27 (UTC)
就修改內容而言，我(＋)贊成本修改，並感謝天邪鬼致力完善方針細節。然而，希望他也明白社群有一定的決策程序，如可能的話，應盡量在程序容許範圍內進行修改。--Temp3600（留言） 2017年7月31日 (一) 08:37 (UTC)

由於多日無新回應，公示七日。--小火車（留言） 2017年8月10日 (四) 06:51 (UTC)

由於多日無新回應，本提案視為通過，公告七日後存檔。--小火車（留言） 2017年8月18日 (五) 05:55 (UTC)

修改機器人方針

最新留言：6 年前9則留言9個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年11月2日 (四) 08:42 (UTC)。

現行條文

===機器人帳號===
...略...
此外，機器人帳戶用戶名應包含「Bot」或「機器人」等標記，以資分辨用戶及機器人所作編輯。機器人帳戶用戶頁上可加上{{bot}}註明。

提議條文

===機器人帳號===
...略...
此外，機器人帳戶用戶名應包含「Bot」或「機器人」等標記，否則必須在每個編緝摘要中均加入Bot或機器人等字眼，以資分辨用戶及機器人所作編輯。機器人帳戶用戶頁上可加上{{bot}}註明。

要每個機器人的用戶都必須有Bot的字眼並不合理，其實最終目的也只是分辦編緝。怎麼就不善用編緝摘要，而必須有用戶名要求呢？--Шәτіт🐷0 2017年10月10日 (二) 08:50 (UTC)

(！)意見這可能造成我們必須要解析summary的困難。例如一筆編輯summary為「避免bot重複編輯這個頁面」、「機器人出錯了 改回來」，那這些編輯可能會被當作機器人的編輯。另外我們也得要考慮到有些時候我們可能僅僅從頁面獲得使用者名稱，之後就要判別使用者的身份、執行某些操作，這樣的操作並沒有經過檢核某個頁面編輯紀錄的過程，因此也就沒有summary可取。這情況下若是沒有限制使用者的名稱，就比較容易出錯誤。另外還應考慮機器人沒有加上bot flag、還沒得到bot flag之申請者的編輯情況，可能連人類都容易誤判。 --Kanashimi（留言） 2017年10月10日 (二) 11:41 (UTC)
(！)意見一個用戶是否是機器人用戶，最終應該還是看是否有 Bot flag （量多，最近更改能過濾）或者是否有機器人申請通過的記錄（量少，或許也就不需要單獨過濾了）。編輯摘要的話，感覺還是管得太細了一點點 .... Dargaseat ‧ c ‧ s 2017年10月10日 (二) 15:23 (UTC)
「要每個機器人的用戶都必須有Bot的字眼並不合理」可否論述不合理的原因？——Aotfs2013 留於 2017年10月10日 (二) 16:05 (UTC)
只是"應"而已，大原則還是bot name能否讓人清楚明白。--Temp3600（留言） 2017年10月10日 (二) 17:20 (UTC)
編緝摘要含有bot字眼，有時候也會與人類編輯混淆，例如編緝摘要中為「bot壞了」，不好分辨。--PatrollerAAAA（討論|留名） 2017年10月11日 (三) 05:16 (UTC)
如有1個未持有機器人權限的人類編輯者提出刪除1個由User:Liangent-bot創建的重定向的刪除討論，在該頁面加上{{Vfd|這是User:Liangent-bot所創建的重定向，但{{link-en}}的參數出現錯誤|r|date=2017/11/02}}，但編緝摘要卻是「User:Liangent-bot根據{{link-en}}的參數錯誤創建」，則該人類編輯者不應視為機器人--林勇智 2017年10月15日 (日) 12:27 (UTC)
我覺得要求以機器人為目的的帳號含bot字眼確實會有容易分辨的好處。如果這樣做法有其他不方便的話，或許可以衡量利弊消除這個規定，但是需要先說明情況——為什麼這個要求不合理，造成了什麼不方便。否則我想這個要求還是保存著好。Bluedeck 2017年10月23日 (一) 05:12 (UTC)

意見徵詢︰機器人活躍度門檻

最新留言：6 年前22則留言6個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年4月17日 (二) 04:29 (UTC)。

本討論已經結束。請不要對這個存檔做任何編輯。

目前而言，《機器人方針》規定機器人活躍門檻為「如機器人賬號及其操作者最近兩年沒有編輯，其機器人權限可被移除。」翻查紀錄，在此除權條件下，有機器人最後編輯時間是零九年，距今幾近十年。姑勿論會否引起系統安全問題，機器人長期沒動作，而編輯環境其實恆年常變，而機器人審核小組無法定期審核各個機器人操作許可，如此一來該等操作許可會否已經與方針指引或者編輯慣例有所矛盾呢？是故，現請諸位就以下問題發表意見。--J.Wong 2018年3月21日 (三) 06:36 (UTC)

甲、機器人不活躍門檻是否應該繼續與操作者掛勾？

如題。而如果操作者活躍，而機器人久未活動，要否重新經過機器人審核小組審核方可重新繼續操作呢？--J.Wong 2018年3月21日 (三) 06:36 (UTC)

建議脫勾，重新申請時或許豁免審核比較好。—AT 2018年3月21日 (三) 15:09 (UTC)
應脫勾，但不必豁免審核，反正BAG成員可自行提出無須測試。JC1 2018年3月21日 (三) 16:40 (UTC)
應脫勾，需重新申請，但建議審核小組視情況予以快速批准（若再次運行無任何問題）。--Xiplus#Talk 2018年3月22日 (四) 13:25 (UTC)
應脫勾，需重新申請。--Temp3600（留言） 2018年3月24日 (六) 07:40 (UTC)

乙、機器人不活躍門檻是否繼續維持於兩年？

如果不建議維持於兩年，那多少為之合適？--J.Wong 2018年3月21日 (三) 06:36 (UTC)

與其他權限看齊，建議改為半年。—AT 2018年3月21日 (三) 15:10 (UTC)
存檔、維護等機器人於首輪運作後可能要一段長時間才須再次運作，建議至少一年。JC1 2018年3月21日 (三) 16:40 (UTC)

其他

就目前機器人方針活躍度要求，兩年不活躍是權限及運行許可一併取消，然而是機器人所有的任務合併計算，再加上操作者是否活躍，若是機器人只執行某一項任務，而另一項任務已有數年沒執行，這並不合理。再者，更重要的事情是編輯環境並非永遠不變，BAG批准一項機器人任務勢必要考量目前的環境能否運行機器人，例如一個長久未執行的存檔機器人一天突然執行，但頁面的版面架構早已改變，於是將存檔搞得亂七八糟，反之，若是一個有持續在運行的機器人，要變更版面架構時，自然會想到有這個存檔機器人，便會通知操作者配合做出修改（這只是一個小舉例，嚴重可能是機器人做出大量不恰當編輯後才被發現）。

因此，我認為應該針對每一項任務單獨設定一個不活躍自動撤銷許可的期限，機器人超過一定期限沒有執行這項任務，許可即被自動撤銷，然而BAG勢必無法定期審視一個任務有沒有過久無執行，因此若要有這項規定，應該是操作者在重新執行這項任務時必須自行確認，或者是當任何人發現許可已被自動撤銷時，向操作者告知，且操作者應當立即停止運作機器人。要重新運行這項任務時必須重新申請，BAG確認在前次批准的條件下重新運行機器人並無問題時，可給予快速批准。--Xiplus#Talk 2018年3月22日 (四) 13:25 (UTC)

立意雖好，但除非能設立中央資料庫集中統整各項permit，否則暫不支持。--Temp3600（留言） 2018年3月24日 (六) 07:43 (UTC)
@Temp3600：這個？--Xiplus#Talk 2018年3月24日 (六) 16:38 (UTC)
可以再寫得清楚些。確保及時更新外，對於只有1個permit的機器人，可列出預定過期時間，長遠而言則要求在編輯摘要寫明在執行那一個任務。--Temp3600（留言） 2018年3月25日 (日) 13:52 (UTC)
@Temp3600：但我上面的說法並非是要BAG或其他人主動定期來審視現有的許可。--Xiplus#Talk 2018年3月31日 (六) 12:41 (UTC)
在我而言這是一個方便性的問題。比如說現實生活中，會有學費單/電費單等提醒你需要到期續約的配套措施。如果要求operator自行記憶每個任務的最後操作時間，我認為過於苛刻。--Temp3600（留言） 2018年3月31日 (六) 16:04 (UTC)
是最後操作時間還是批准時間？批准時間可以列表紀錄，但最後操作時間就很困難了，而我想最清楚最後操作時間的應該是操作者本身。--Xiplus#Talk 2018年4月2日 (一) 09:09 (UTC)
倒回來，我想一個合適的機器人操作者對操作環境的改變會有適當的反應，合適則繼續操作，不合則重新討論。當機器人一直運作（其他任務），並於操作者控制之下，由其自行確認，有疑問提出就好。題外話，以前我曾經把已完成的任務劃線，結果[1]。JC1 2018年3月26日 (一) 20:43 (UTC)
這個，個人覺得在該操作許可留言，並通知機器人審核小組成員，會是比較好的做法。--J.Wong 2018年3月27日 (二) 03:03 (UTC)
  • 稍為歸納一下︰一、機器人及操作者不活躍門檻應該脫勾；二、機器人門檻則建議由兩年降為半年至一年；三、如果機器人久未活躍，需重新申請。機器人審核小組如認為可以，則可快速批準。--J.Wong 2018年4月9日 (一) 14:23 (UTC)

機器人方針修訂

最新留言：6 年前6則留言3個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年5月1日 (二) 05:24 (UTC)。

本討論已經結束。請不要對這個存檔做任何編輯。

基於上列意見徵詢結果，建議對《機器人方針》作出以下修訂。

現行條文

活躍度要求 如機器人帳號及其操作者最近兩年沒有編輯，其機器人權限可被移除。移除前，應先到操作者的用戶討論頁留言，並給予一星期的通知期。如操作者日後回到維基，並希望再次運作機器人，必須重新申請。

提議條文

活躍度要求 如機器人帳號最近一年沒有編輯，其機器人權限可被移除。移除前，應先到操作者的用戶討論頁留言，並給予一星期的通知期。無論操作者是否活躍，如果所持機器人久未活躍，以致權限已經撤銷，則必須重新申請操作許可。機器人審核小組成員如認為妥當，則可以快速批准操作。另外，亦建議操作者就機器人各項已批准任務最後操作日期留有紀錄，以及如某項任務已經久未進行，就算該項任務已經獲得批准，再次運行時仍應留意機器人設定是否與現行編輯環境相配合。操作者如認為某項許可已經再無需要使用，則可於該操作許可留言，並通知任何機器人審核小組成員處理。其他用戶如果發現某機器人某項任務已經沒有執行超過一年，則可按上列程序要求覆核。

  • 一年而非半年，雖然意見徵詢結果之中，有不少用戶認為應該與其他權限看齊，將門檻降至半年。唯當中，有用戶指出可能某些任務間隔是會比較長。此可能的確不能輕易排除，是故將期限定為一年。至於意見徵詢其他一節之中，意見指應該按已批准任務最後操作日期計算，此方向其實可取，惜未能議出具體執行之策，掣肘之處仍然不鮮。今嘗折衷而為，鼓勵操作者自行保留紀錄，並於停擱後，再次執行前，檢查是否仍與編輯環境相配合。亦指出操作者可如何申請註銷已無用操作許可。及提示其他用戶如發現則可以按相關程序申請覆核。謹此。--J.Wong 2018年4月9日 (一) 15:53 (UTC)
(＋)支持--Temp3600（留言） 2018年4月12日 (四) 05:46 (UTC)
(＋)支持，較兼顧現實的做法。--Xiplus#Talk 2018年4月13日 (五) 13:25 (UTC)

再三強烈要求規範WP:MASSCREATION

最新留言：6 年前42則留言15個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年6月9日 (六) 05:20 (UTC)。

本討論已經結束。請不要對這個存檔做任何編輯。

WP:MASSCREATION要求用戶以自動或半自動方式批次創建條目或頁面分類前，必須先提出申請。「批次」指50項編輯或以上。你應先到互助客棧及相關專題尋求共識。操作者必須確保所創建的條目符合社群的要求。但在下發現不少用戶未能符合以上要求，甚至拒絕溝通，故以在下建議修改MASSCREATION，建立一些基本的要求，並開始嚴格拆行WP:BOTPOL，請注意：這不是收緊關注度或要求刪除舊有條目，而是要求用戶及後使用機器人時更為謹慎。

絕大部分情況下，以機器人建立的條目皆沒有人維護，故此創建時應訂立更高標準。在下建議要求使用機器人創建條目時須符合下列條件，否則停止創建：

我認為必須要有一項參考資料、一導航模板合理，但資訊框並非必需。--【和平至上】💬📝 2018年4月28日 (六) 06:13 (UTC)
沒有人說是完整的資訊框，以最近的弗爾克謝什蒂鄉為例，單以現有的名稱、原名、上級行政區、面積、人口去建立資訊框，完全足夠，也無須另外找資料。JC1 2018年4月28日 (六) 06:38 (UTC)
@Yangfl、Justincheng12345： 曾在IRC上多次請求他人對TMBW是否使用了機器人進行評論，但是因為技術限制沒有任何依據證實，所以我只能選擇AGF。此外，據我所看到的情況，TMBW翻譯的來源語種（例如德語、愛沙尼亞語等）早已採用使用直接引用wikidata作為infobox數據顯示來源的做法，所以，即使使用翻譯工具也不能在原始碼里找到資訊框資料來。--雲間守望淡出中，有事請發郵件 2018年4月28日 (六) 10:05 (UTC)
「弗爾克謝什蒂鄉是羅馬尼亞的鄉份，位於該國西南部，由戈爾日縣負責管轄，面積84平方公里，海拔高度188米，2007年人口3,597，人口密度每平方公里43人。」不論如何，他就是已經取出那些資料了吧？別說創建條目之時有raw data，就算是現在用regex也能提出再放入infobox內吧？另外就是BOTPOL從來沒有說一定要某種程式才算機器人，WP:MEATBOT：「在處理爭議時，那些編輯是由機器人、使用半自動工具的編者、或是全手動所做並不重要；」JC1 2018年4月28日 (六) 10:35 (UTC)
@Justincheng12345：其取出的系舊的資料，我說明的情況是在於較新的資料其不可能直接由Wikidata摘取出來（技術要求挺高的）。不過講道理，他這樣做確實嚴重擾亂站務秩序了，而且如果用regex確實能放進infobox去，我承認。（在下曾為該用戶擦過屁股，表示深受其害。）--雲間守望淡出中，有事請發郵件
話說其實從wikidata取資料很簡單了，就以羅馬尼亞鄉份為例，來這裏，然後下載csv就可以了。另外依照wikidata自動更新未必可取，很容易做成內文與infobox不對應。JC1 2018年4月29日 (日) 06:06 (UTC)
(＋)支持：我曾有使用機器人創建條目的計劃。但是我也支持以下要求：創建條目時應盡可能確保資料庫為最新版本；建立頁面填入已創建的條目，方便他人檢查及更新；不應當是孤立、未歸類、斷鏈頁面。--雲間守望淡出中，有事請發郵件 2018年4月28日 (六) 11:42 (UTC)

@WQL：，我想了數天強制使用資訊框或許並非完全適合，例如應該使用文中的資料還是最新的資料之類。但想問一下有甚麼原因讓你不支持強制參考資料和導航模板？我相信這兩項很簡單吧？使用的資料庫本身就是一個參考資料，導航模板簡單而言也可以把同一省份的某級行政區條目放在一起就好，更何況從英語版抄過來使用翻譯連結小工具也是非常容易。JC1 2018年5月3日 (四) 13:40 (UTC)

MASSCREATION第一版

現行條文

以自動或半自動方式批量創建條目或頁面分類前，必須先提出申請。「批量」指50項編輯或以上。你應先到互助客棧及相關專題尋求共識。操作者必須確保所創建的條目符合社群的要求。

更簡單的方法是減少創建的條目數量，或先在各屬專題的子頁面創建條目，由其他編輯檢查後，再移動到條目空間。這些方法不用申請機器人，也更容易得到社群的支持。

提議條文

以自動或半自動方式批量創建條目或頁面分類前，必須先提出申請。「批量」指50項編輯或以上。你應先到互助客棧及相關專題尋求共識。操作者必須確保所創建的條目符合社群的要求。

更簡單的方法是減少創建的條目數量，或先在各屬專題的子頁面創建條目，由其他編輯檢查後，再移動到條目空間。這些方法不用申請機器人，也更容易得到社群的支持。

一般而言，除非社羣或機器人審核小組提出豁免，由機器人創建的條目須達致以下標準：

  1. 創建條目時應盡可能確保資料庫為最新版本
  2. 建立頁面列出已創建的條目，方便他人檢查及更新
  3. 頁面應包含最少一項參考資料及一導航模板
  4. 頁面不能為孤立頁面、未歸類頁面、斷鏈頁面
(＋)贊成：合理的要求。--【和平至上】💬📝 2018年5月9日 (三) 14:26 (UTC)
完全(＋)贊成：方便巡查（反正我也不會用MASSCREATION）。ŚÆŊMØŠĀ 2018年5月13日 (日) 01:17 (UTC)
(＋)贊成：第三項深得我心。--Temp3600（留言） 2018年5月14日 (一) 16:43 (UTC)
  • 僅反對導航模板。本人的意見是：
    • 第3項：條目應被維基化，應有至少一項參考資料。
    • 第4項：條目不能為孤立頁面。
  • 維基化包含添加分類、連結（即避免斷鏈頁面）。導航模板不是所有批量建立都有，可能也不是都合適（再舉個例子吧，無編號的道路或街巷、立交橋），不應強制要求。反而是考慮到批量建立的條目都依賴于格式化信息，有條件強制要求信息框。 --達師 - 370 - 608 2018年5月14日 (一) 17:55 (UTC)
  • 如果以持有機器人權限的帳戶建立條目，因為機器人自帶巡查豁免（autopatrol），那麼建立條目的品質應該跟能獲得巡查豁免權的情況看齊？--Xiplus#Talk 2018年5月14日 (一) 23:22 (UTC)
說遠一點，遇到這種情況，應要求創建者先弄幾個條目出來，大家自然心裏有數。問題是:如果有人一來就手動大建特建呢?--Temp3600（留言） 2018年5月15日 (二) 11:56 (UTC)
這幾個月還多了IP用戶不論條目質量就把孟加拉的條目隨意地開，勸止都不聽呢。--owennson（聊天室、獎座櫃） 2018年5月15日 (二) 16:27 (UTC)
(＋)贊成--Hello903hello 留言·貢獻 回覆用{{ping}} 2018年5月16日 (三) 08:56 (UTC)

我暫時總結一下，社羣主要有以下數項疑慮：

  1. 導航模板是否必須。參考達師和快龍的意見，改為某些條目才須導航模板如何？我認為最起碼可以為行政區。
  2. 資訊框是否必須，這個要社羣先回答WQL的問題。例如，機器人所使用的資料庫與wikidata的有所不同（或者資料陳舊），而某些原因未能全面採用wikidata的資料，那麼資訊框的內容應該使用本來的資料庫還是wikidata？
    1. 這個問題於其他條目也是同理，若日後有模板可直接從wikidata取得資料，那麼可以容許資訊框與內文不對應嗎？
  3. autopatrol本來就沒有品質要求，只是創建條目數夠了就有了
  4. 最後，一直以來未經批准下運行的機器人會立刻封禁，我相信MEATBOT也是同理，當然作為主賬號可先作通知或警告。

可以先討論一下上述數項。JC1 2018年5月16日 (三) 13:05 (UTC)

  • JC1君︰首先，閣下要明白此乃方針，無可能列出所有條目範疇應該如何辦，所以可以做的是，改為「建議」。又或者提醒操作者，如所創範疇有導航模板或資訊框就應該加上，而非「必須」。巡查豁免審批是應該也要看質素，看條目質素是否可免於巡查。--J.Wong 2018年5月20日 (日) 03:41 (UTC)
    • WP:VD也是方針，其亦於沒有窮舉的情況下列出非常多的破壞類型，同理，列出部分應受較多限制的條目範疇為何又有所分別？巡查豁免當然應該要看使用者一向所創條目的質素，但其實每個管理員標準不一，而方針亦只是指「熟知維基方針及指引（特別是生者傳記和關注度）的可信賴用戶」，根本沒有清楚準則。JC1 2018年5月20日 (日) 08:39 (UTC)
    • 兩者並不可比。《破壞方針》沒能窮列所有情況，與此提案是否應該按實況給予足夠豁免，根本完全無關。閣下只要再修改草案，給予足夠豁免，其實問題就迎刃而解。--J.Wong 2018年5月21日 (一) 12:46 (UTC)
      • 當然有關，重點就是方針可以在無需窮舉之下列出部分應當處理的情況，故此其「無可能列出所有條目範疇」，正如「無可能列出所有破壞行為」。我的提案比給予豁免更為寬鬆，只是要求部分已列出的條目範疇受較多限制，例如只有行政區劃條目需要符合導航模板的額外要求之類，其他按原本維基化/孤立頁面的要求處理。JC1 2018年5月22日 (二) 06:51 (UTC)
      • 更何況「除非社羣或機器人審核小組提出豁免」一句已符合給予足夠豁免，hell，可以說已經給予全面豁免了。JC1 2018年5月22日 (二) 06:57 (UTC)
      • 之所以言之不可比是因為《破壞方針》有給予明確定義，然後不窮盡例子只為說明此項定義。亦因如此，《破壞方針》可以不窮舉例子，正如《收錄準則》一樣。但此處，閣下草案是定出標準，而此等標準並非用以說明某個定義。而且現在就是提示閣下草案有值得斟酌之處，提供豁免固然是好，但並沒有根本解決缺漏。所以才叫閣下修改字眼。就第三項，無論是上列達師君所提議，抑或修改成「頁面應包含最少一項參考資料，以及如果條目範疇有相應導航模板，則亦應該包含其中。」，個人都能夠接受。請君考慮，在下無意刁難，只希望草案不會有已知缺憾。--J.Wong 2018年5月23日 (三) 02:41 (UTC)

MASSCREATION第二版

現行條文

以自動或半自動方式批量創建條目或頁面分類前，必須先提出申請。「批量」指50項編輯或以上。你應先到互助客棧及相關專題尋求共識。操作者必須確保所創建的條目符合社群的要求。

更簡單的方法是減少創建的條目數量，或先在各屬專題的子頁面創建條目，由其他編輯檢查後，再移動到條目空間。這些方法不用申請機器人，也更容易得到社群的支持。

提議條文

以自動或半自動方式批量創建條目或頁面分類前，必須先提出申請。「批量」指50項編輯或以上。你應先到互助客棧及相關專題尋求共識。操作者必須確保所創建的條目符合社群的要求。

更簡單的方法是減少創建的條目數量，或先在各屬專題的子頁面創建條目，由其他編輯檢查後，再移動到條目空間。這些方法不用申請機器人，也更容易得到社群的支持。

一般而言，除非社羣或機器人審核小組提出豁免，由機器人創建的條目須達致以下標準：

  1. 創建條目時應盡可能確保資料庫為最新版本
  2. 建立頁面列出已創建的條目，方便他人檢查及更新
  3. 條目應已維基化，並有至少一項參考資料。
  4. 頁面不能為孤立頁面。
  5. 如條目範疇有相應導航模板，亦應包含其中。
  6. 可行情況下，條目應附有訊息框。

建議適度擴大機器人的使用範圍

最新留言：6 年前13則留言8個人參與討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年6月28日 (四) 09:41 (UTC)。

嘛，也不是第一次提了，只是最近這三天的經歷，感受更深了不少。

我希望，機器人不僅僅限於現在的補個標點、標記/補充替換個死連結、發個通知什麼的這種工作，應該進一步投入到人力資源補充、反破壞日常維護的工作中去。

165.84.176.62提出「為什麼黃智雯、李佳芯、蔡思貝、甚至張可頤等等等等大部分演員可以有性質?」，這是個好問題。角色性質，早就有共識原則上禁止使用了（我個人一直是有條件接受），那為什麼這麼多條目變成了漏網之魚？顯然，是執行力度的問題，根本性問題是缺乏人力，而wiki太大了（指望我一個人管了所有TVB條目這事顯然也不現實，於是只能儘可能多管幾個，到最後，幾個有人日常維護的，反倒成了異類，大部分其他條目在野蠻生長。）

而今天下午，本來國籍的問題，北極企鵝團路過看見，已經幫忙弄好了，下午我上來，當時Jasonloi1997已經在那裡了，結果陳奕迅等三個條目，我前後大概頂了20分鐘多一點（基本到極限啦，很久沒這麼幹過了。最後沒徹底頂住不說，我倒收到了3RR通知...  囧rz…… 剛才我查了一下記錄，管理員處理完已經是晚上很晚了）。

我想說，無論是角色性質，還是國籍破壞。它們都有固定的編輯模式/內容，既然這樣，是否可以投入機器人進行維護工作，代替純人工？（特別是下午那20分鐘，真是夠嗆）

--我是火星の石榴（留言） 2018年6月13日 (三) 17:32 (UTC)

ORES--百無一用是書生 (☎) 2018年6月14日 (四) 02:06 (UTC)
  • 其實這話題與機器人方針沒太大關係……請善用已有科技。--J.Wong 2018年6月14日 (四) 05:07 (UTC)
  • 這有點像是在說enwiki的User:ClueBot NG，會自動識別並回退可能的破壞編輯。不過zhwiki編輯量還沒那麼大，AF應該夠用。--Suaveness（對話．貢獻） 2018年6月14日 (四) 14:30 (UTC)
  • (？)疑問：@Red16：什麼叫做角色「性質」？ 他們又不是化學物質，有什麼性質？如果是訊息框，未見禁止加入訊息框的共識。--　宇帆（維基貢獻十周年！留言·歡迎簽到[試用小工具]） 2018年6月15日 (五) 04:53 (UTC)
    • (：)回應：就是男/女1/2/3/4號...然後其他人的粉絲會過來說，我們才是1號，你們根本是配角，於是就這麼開始輪上了...那wiki不就是變成了兒童遊樂園了嘛。當年kellymok被封禁的理由不就是這個？長期出沒解除了？我查了一下並沒有啊。--我是火星の石榴（留言） 2018年6月15日 (五) 05:07 (UTC)
  • 「角色性質，早就有共識原則上禁止使用了」不了解，可設定方針、設定防濫用過濾器，用不上機器人吧。機器人對有表格內容的清理並不有效，機器人回退還可能造成編輯戰、漏網/繞過，如Liangent-bot的反簡繁破壞。如果共識確定並且內容規律，可以請求機器作業來糾正。--YFdyh000（留言） 2018年6月15日 (五) 14:40 (UTC)
    • 我自己也想不明白，為什麼編輯共識的討論記錄會找不到？但是相關封禁記錄肯定全部都在，但是最早的依據存檔找不到，這我們是不是要把那一堆持續出沒的給放出來？  囧rz…… 只能麻煩管理員去找了，如果十幾年的記錄就找不到的話(等於數據會自動永久性丟失) 這沒什麼好說的了。
過濾器難道不是需要管理員來設置的麼？我自己費碼農出身，精密模板這種東西肯定算了。
另，現在另一個大問題是，既有內容的大規模清理，不使用機器人的話，不具可行性吧？你要都丟給我一個人，我肯定不幹了。--我是火星の石榴（留言） 2018年6月15日 (五) 18:39 (UTC)
(※)注意：禁止加入訊息框的共識不存在。--　宇帆（維基貢獻十周年！留言·歡迎簽到[試用小工具]） 2018年6月16日 (六) 01:40 (UTC)
(※)注意：禁止加入訊息框的共識不存在，化學性質信息框、演算法性質信息框、多面體性質信息框......等等並非未經篩選的資料，且禁止加入訊息框的共識不存在，乃至角色性質訊息框，無明顯共識，參與討論人數過少，想說你們正在WP:POINT。--　宇帆（維基貢獻十周年！留言·歡迎簽到[試用小工具]） 2018年6月16日 (六) 09:42 (UTC)
  • 事實上WP:BOTPOL並未直接對這類任務作出特定的限制。但是從機器人的三大原則（有用、無害、有效）來看，顯然這類機器人不如過濾器有用和有效，因此獲批的可能性不大。--Antigng（留言） 2018年6月20日 (三) 14:57 (UTC)

方針小修

最新留言：6 年前2則留言1個人參與討論

見Special:Diff/50250102。-- Junjie Yuan（留言） 2018年7月4日 (三) 11:26 (UTC)

我覺得這個方針要改的地方還有很多，不過最近沒什麼時間，先不管了。--Junjie Yuan（留言） 2018年7月4日 (三) 11:28 (UTC)

Techadmin 能擁有adminbot嗎？

最新留言：5 年前19則留言10個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2019年4月19日 (五) 08:14 (UTC)。

最近liangent bot 停運，大家都吃了不少苦頭。但可惜目前的管理員暫時未有時間研究如何維修它。能不能將adminbot的擁有人放寬到techadmin呢，讓多點人參與研究呢？

  • 界面管理員權限的確在 Liangent-bot 的功能上沒什麼可做的，除非把 DYK 模板放進 MediaWiki 名字空間（囧），這樣自帶全保護且 IA 也可以編輯。--Tiger（留言） 2019年4月10日 (三) 01:14 (UTC)
  • 代碼確實需要多次調試並且更改，不太可能每次調試、甚至緊急的更改都要耗費寶貴管理員的時間與精力來部署軟體。若是以參與處理技術性站務為主來申請管理員，不曉得各位覺得如何？ --Kanashimi（留言） 2019年4月10日 (三) 08:54 (UTC)
  • 其實是有擅長技術站務而且也活躍的管理員在，如果給他們的話，他們可自行調試、更改。如果他們都無法完成這個工作，而且正好有一個值得信任的非管理員願意做這件事，那麼此次作為例外，給他們一個含有管理員權限的機器人帳戶我覺得可以考慮。--Tiger（留言） 2019年4月10日 (三) 09:16 (UTC)
  • （值得信任的水準恐怕要很高，就是和管理員一致，只是不去考察那位用戶其他方面的站務能力）--Tiger（留言） 2019年4月10日 (三) 09:21 (UTC)
可以考慮允許界面管理員或者面向技術維護的類似管理群組的申請帶管理員權限的機器人，不過需要遵守更嚴格的規定，例如代碼要公開review；只限於任務內的操作（除了一些合理的調試行為）；一經發現違規、超範圍操作、或者涉及公器私用的，立即除權，無合理解釋的話永久不得再申請。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年4月11日 (四) 00:28 (UTC)

對維基百科:用戶頁、維基百科:機器人方針及相聯頁面的合併更新

最新留言：4 年前15則留言7個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2020年3月9日 (一) 00:14 (UTC)。

已解決
下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

目前的用戶頁方針對機器人帳號等合規附屬帳號的用戶頁沒有明確的規範。此外，部分機器人的用戶子頁設有技術開關，如User:Liangent-bot/message，一旦遭到錯誤的更改，可能影響到眾多用戶。現擬對此作出明文規定：

Wikipedia:用戶頁

於目前「從我的用戶頁上有哪些其他信息可以被別人看到？」下，新增一章：

現行條文

無。

提議條文

機器人及其他合規多重帳號的用戶頁 一般來說，機器人及其他合規多重帳號用戶頁的所有權歸這些帳戶的操作者所有；如果機器人由多人一起操作，則一般而言，所有操作者都具有所有權。操作者對這些用戶頁進行創建、修改、申請進行管理操作時，等同於對自己的用戶頁空間進行操作。

Wikipedia:機器人方針

於「機器人的使用」下添加三級標題，為：

現行條文

無。

提議條文

機器人的用戶頁 機器人可按實際需求設立用戶頁及用戶子頁面。這些頁面的管理權屬於機器人操作者。由於此類頁面有一定系統管理功能，管理員可對它們實施預防性保護。

Wikipedia:保護方針

修改Wikipedia:保護方針#不同的保護期限，增加：

現行條文
  • 保護一些「系統管理」頁面，包括許多編輯用的模版，例如刪除告示、小作品模版等。
  • 保護MediaWiki的名字空間，以及嵌入包含的頁面，這些頁面會影響所有用戶的系統界面。
提議條文
  • 保護一些「系統管理」頁面，包括許多編輯用的模版，例如刪除告示、小作品模版等。
  • 保護有「系統管理」性質的機器人子頁面。
  • 保護MediaWiki的名字空間，以及嵌入包含的頁面，這些頁面會影響所有用戶的系統界面。

Wikipedia:傀儡

修改公開備用帳號一節：

現行條文

== 公開備用帳號 ==

使用多重帳號的用戶應當明示帳號間的關係，除非這樣做會違背合理使用多重帳號的目的。明示的方式是在備用帳號用戶頁上使用模板{{User Alternate Acct|主帳號名}}。在主帳號頁上亦可加上{{User Alt Acct Master}}標記。

提議條文

== {{新增條文|公開多重帳號間的關係}} ==

使用多重帳號的用戶應當明示帳號間的關係，除非這樣做會違背合理使用多重帳號的目的。明示的方式之一是在子帳號的用戶頁上使用諸如{{User Alternate Acct|主帳號名}}、{{Bot|主帳號名}}等模板。在主帳號頁上亦可加上{{User Alt Acct Master}}標記。經標記後，主帳戶對這些用戶頁進行創建、修改、申請進行管理操作時，等同於對自己的用戶頁空間進行操作。

個人有兩隻帳號，目前這隻比較活耀比較新，另一隻貢獻次數比較多。到時你們討論完成後請題醒或指導我如何標記Heartingvia（留言） 2020年2月22日 (六) 03:55 (UTC)
不同意必須要用模板作出合理使用多重帳號聲明，我認為只要用戶頁具有適切的說明文字即可。ꓢꓯꓠꓟꓳꓢꓮ COVID-19 2020年2月23日 (日) 06:13 (UTC)
"使用多重帳號的用戶應當明示帳號間的關係"是舊有的方針條文。我不太清楚當初為什麼會譯做"應"。--Temp3600（留言） 2020年2月23日 (日) 13:54 (UTC)
條文是「使用多重帳號的用戶應當明示帳號間的關係」沒錯，其實沒了「應」這個字更好，不過這要另外提案。我説的是我認為只要用戶頁具有適切的說明文字説明帳號間的關係（例如A用戶和B用戶是同一個人操作的）就行，不一定要用模板顯示。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫長夜 2020年2月23日 (日) 14:26 (UTC)
"明示的方式之一是"就行了吧。--Temp3600（留言） 2020年2月23日 (日) 15:38 (UTC)
接受，其實只要不是唯一就可以。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫長夜 2020年2月24日 (一) 02:16 (UTC)
好，已改。--Temp3600（留言） 2020年2月24日 (一) 11:41 (UTC)
初步不反對。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫長夜 2020年2月24日 (一) 11:43 (UTC)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
取自「https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:機械人方針/存檔一&oldid=68173039」
返回專案頁面「機械人方針/存檔一」。