维基百科:互助客栈/方针

维基百科,自由的百科全书
跳转至: 导航搜索

互助客棧消息发表 · 方针 · 技术发表 · 求助发表 · 条目探讨发表 · 其他发表 知识问答发表
快捷方式
WP:VPP
Nuvola apps edu miscellaneous.svg

本頁提出或讨论维基百科政策、方针,请参看方針與指引方针列表
繁简处理的议题请前往字词转换讨论页
条目应当如何编辑才符合中立性原則寻求社群共识,请前往条目探讨留言。 請注重禮儀及遵守方針與指引,一般問題請至互助客栈/其他知识问答提出,留言后请务必签名(点击 Vector toolbar signature button.png )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
存档图像
互助客栈(方针)档案馆
编辑

2003年 5月或之前 6 7 8 9 10 11 12
2004年 1 2 3 4 5 6 7 8 9 10 11 12
2005年 1 2 3 4 5 6 7 8 9 10 11 12
2006年 1 2 3 4 5 6 7 8 9 10 11 12
2007年 1 2 3 4 5 6 7 8 9 10 11 12
2008年 1 2 3 4 5 6 7 8 9 10 11 12
2009年 1 2 3 4 5 6 7 8 9 10 11 12
2010年 1 2 3 4 5 6 7 8 9 10 11 12
2011年 1 2 3 4 5 6 7 8 9 10 11
2012年 1 2 3 4 5 6 7 8 9 10 11 12
2013年 1 2 3 4 5 6 7 8 9 10 11 12
2014年 1 2 3 4 5 6 7 8 9 10 11 12
2015年 1 2 3 4 5 6 7 8 9 10 11 12
2016年 1 2 3 4

公告板

目录


提議獨自設立「大量訊息發送者(Massmessage sender)」權限[编辑]

昨日我在瀏覽Meta的頁面時,看到了這個請求,之後我研究了一下m:MassMessage這項功能。隨後我與@和平奮鬥救地球君私底下互相腦力激盪了一番,得出以下結果:目前中文維基百科只限管理員可以大量發送訊息,所以我覺得可以獨自設立一個「大量訊息發送者(en:Wikipedia:Mass Message Sender)」權限,方便非管理員的用戶使用此功能。例如動員令時,可以使用此功能對用戶發送動員令邀請,還有發送動員令已完成通知、未完成通知等訊息,未來欲復刊的《維基人》也可以使用此功能發送,故在此提案。而相關的使用方針草稿,我已經先放到WP:大量訊息發送者內,目前正在進行翻譯。請各位踴躍對增設此一權限以及其他相關事項發表意見,謝謝!--Bowleerin留言) 2016年2月29日 (一) 08:28 (UTC)

目前中文版似乎还没真正使用过这个功能--百無一用是書生 () 2016年2月29日 (一) 12:51 (UTC)
@Shizhao:目前我只知道@AddisWang君和@Jasonzhuocn君兩位有使用過此功能,不過一些元維基的Newsletter都是使用此功能發送,我覺得可以在這邊多加運用。--Bowleerin留言) 2016年2月29日 (一) 14:52 (UTC)
我沒有使用過這功能,我只用人工發信。--Jasonzhuocn留言) 2016年2月29日 (一) 14:56 (UTC)
囧rz...我記錯了,抱歉--Bowleerin留言) 2016年2月29日 (一) 15:30 (UTC)
没必要吧。--Antigng留言) 2016年2月29日 (一) 15:00 (UTC)
感覺容易被濫用,需要一定保障措施。Innocentius留言) 2016年2月29日 (一) 15:01 (UTC)
相關規範當然是要訂定的,可一起討論。- 和平、奮鬥、救地球!(留言)自然條目提升宗教專題於 2016年2月29日 (一) 15:21 (UTC)
建議採信任制,如同目前的巡查權、回退權一樣。--Temp3600留言) 2016年2月29日 (一) 16:38 (UTC)
发送的讯息我从哪里接收?--Gqqnb留言) 2016年3月1日 (二) 07:33 (UTC)
話說FLOW支援群發功能嗎?- 和平、奮鬥、救地球!(留言)自然條目提升宗教專題於 2016年2月29日 (一) 15:22 (UTC)
(+)支持,當然可以啊!遠比直接請求管理員來群發訊息快上好幾倍,故支持設立大量訊息發送者(Massmessage sender)的權限。--深愛學習的Engle躍】 2016年3月1日 (二) 01:10 (UTC)
上届动员令是我用WP:AWBWP:BOT群发的,如果有Mass Messages的话效果会拔群。--Walter Grassroot () 2016年3月1日 (二) 06:09 (UTC)
滥用不是害怕的原因。直接写个脚本,谁都能大量发送。而且还免费正当刷编辑23333证监会那次传单事件不就是AWB干的。Bluedeck 2016年3月1日 (二) 07:30 (UTC)
bot出问题了可以停下,这个出问题了停得下来吗?--Antigng留言) 2016年3月1日 (二) 07:35 (UTC)
我倒是能够希望推广群Ping,这个总比单独发传单要更礼貌点。就是不理解为什么在微博上@很多名人都没事情,结果到维基百科上都成了骚扰。真把自己当成国家领导人。--Walter Grassroot () 2016年3月1日 (二) 07:41 (UTC)
有些人是关了ping的,最著名的例子@user:Jimmy Xu(反正关了我ping你也不要紧吧,对吧)。@user:Walter Grassroot,我觉得那是因为名人从来不理大家的@。@user:Antigng,你说的好像是对的。那么你认为以后群发就用bot吗?Bluedeck 2016年3月1日 (二) 08:18 (UTC)
是。--Antigng留言) 2016年3月1日 (二) 08:37 (UTC)
user:antigng[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]然而我突然想起async请求的bot也是(事实上)一瞬间完成编辑的。。Bluedeck 2016年3月2日 (三) 22:31 (UTC)

看看大家對於大量訊息發送者門檻的看法為何?--深愛學習的Engle躍】 2016年3月2日 (三) 07:04 (UTC)

  • @Walter GrassrootAntigng小躍Temp3600Lnnocentius:@BluedeckGqqnbLiaon98:在這邊一起回覆各位。其實這個功能在發送通知(像是動員令主持人發送的動員令完成通知),以及像《維基人》這類刊物等等這類需要大量在用戶討論頁發送的通知時,會較方便些。如各位所知,元維基的《技術新聞》以及《視覺化編輯器電子報》這類的Newsletter,也都是使用此功能發送的。而就像和平君一開始說的,此權限可以分為「臨時」與「長期」。 以即將到來的第十四次動員令舉例來說:未來被選出來的動員令主持人們,管理員可以授予其「臨時的」大量訊息發送權,以便發送各種動員令的通知(像是:已完成通知、未完成通知,而已完成通知又依各種不同的相對應頭銜再細分。)。而以未來即將復刊的《維基人》舉例,其相關的負責人們,管理員可以授予其「長期」的大量訊息發送權,以便發送刊物至訂閱者的討論頁。元維基的說明頁面有說到,大意是:「發送者須為自己的編輯負責,包括訊息內容、排版等等事項。」,我也覺得可以比照現行的申請巡查權及申請回退權的方法實行「大量訊息發送權」的申請,不過考量此權限會影響到大量用戶對話頁的特殊性,在訂定此權限的申請門檻時,可以訂的高一些,最主要以「可信用戶」為主。而目前WP:大量訊息發送者我希望能夠在近期翻譯完成,以便討論,並再依這邊的討論結果作修正,也歡迎大家一起參與翻譯工作。--Bowleerin留言) 2016年3月2日 (三) 04:47 (UTC) (不好意思搬至此地留言)--深愛學習的Engle躍】 2016年3月2日 (三) 07:10 (UTC)(我先將小躍之前另外新開的段落合併起來,一起討論。)--Bowleerin留言) 2016年3月2日 (三) 15:14 (UTC)
    • @Bowleerin:這還要看看其他人的意見,個人覺得用大量訊息發送還不錯,不過要審慎使用。--深愛學習的Engle躍】 2016年3月2日 (三) 07:15 (UTC)
活动类的个人建议可以临时授予活动主办人这个权限,活动结束后收回。另外,大量訊息發送的使用,目前各项目通行的做法是,用户或社群有接受该类消息的意愿,才会把该类消息推送到这些用户和社群去。而不是像垃圾邮件那种,不管用户愿不愿意接受,都直接发送过去--百無一用是書生 () 2016年3月2日 (三) 09:12 (UTC)
强烈要求默认opt-out。--Kuailong 2016年3月2日 (三) 14:21 (UTC)
user:Kuailong[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]默认opt out就没有继续讨论的意义了。因为默认opt out等于直接把这功能废了。我认为现在讨论的默认前提就是默认opt in的情况下如何减少伤害增加效率。Bluedeck 2016年3月2日 (三) 22:29 (UTC)
没看明白,谁被授予了?--Jimmy Xu 2016年3月2日 (三) 09:50 (UTC)
@小躍:解釋一下您開的標題意義吧。- 和平、奮鬥、救地球!於 2016年3月2日 (三) 10:18 (UTC)
@小躍:我將您另外新開的新段落合併了,並將您留下的導言直接併入討論。而其他的討論排版再視此討論後續的情況進行相對應的排版處理。--Bowleerin留言) 2016年3月2日 (三) 15:14 (UTC)
我的意思是,现在的一般做法是类似于这样的:en:Wikipedia:Wikipedia Signpost/Tools/Spamlist,需要用户自己亲自动手把自己加入到发送列表里--百無一用是書生 () 2016年3月3日 (四) 01:52 (UTC)
我也覺得在發送前,需要先建立一份適當的發送列表。而目前現有的一些發送列表(例如WP:DC/IL的白名單),我覺得可以直接應用來發送大量訊息。而用戶如果不希望收到任何由大量訊息發送功能所發出的訊息,可以將其用戶討論頁加入到Category:不接受消息发送分類內。--Bowleerin留言) 2016年3月3日 (四) 05:18 (UTC)
在下在想,這個權限並不像巡查和回退權如此有廣泛和實際的用途,按照巡查和回退的方式進行授權是否有些不妥?何況,一般用戶就算拿到了這個權限又能做什麼呢...Innocentius留言) 2016年3月3日 (四) 05:25 (UTC)
@Lnnocentius:我認為這個權限是給「有需要的人」使用的。此功能對於在某項活動期間(例如動員令時)發送相關活動通知,或是需要定期發送大量訊息(例如《維基人》的發送)時,是很方便的一項功能。如果這些事項的負責用戶不是管理員,那麼在需要發送大量訊息時,則可能需要另尋方法發送,或向管理員提交發送訊息請求。我覺得,如果按照目前申請巡查權與回退權的方式進行授權,或許並不會不妥,就像目前的AWB權限申請,跟申請巡查權或回退權的方式是一樣的。不過我覺得在此權限申請時,申請者需詳細說明申請的原因(哪項計畫需要使用、欲發送至哪些用戶,以及其他細項,可再討論),同時管理員也需要判斷這項請求,是否真正需要此權限才能進行,再依情況授予權限。這就像是使用AWB,如果只是要執行「一兩項短期且量少的工作」,可以委託已經有AWB使用權的用戶執行即可。--Bowleerin留言) 2016年3月3日 (四) 12:52 (UTC)
名称太长,建议改作群发消息者。--蓝灯 留言 2016年3月3日 (四) 08:20 (UTC)
我覺得使用「大量訊息發送者」即可,而此權限也有一簡稱:「MMS」(MassMessage Sender)。就像是「自動維基瀏覽器使用權」可以簡稱為「AWB使用權」一樣。--Bowleerin留言) 2016年3月3日 (四) 12:52 (UTC)
@BowleerinWP:DC/IL这样的不行,因为MMS使用特殊格式,例如这样:{{#target:User talk:Bowleerin}},才可以发送消息。而且把WP:DC/IL上的列表直接转成MMS格式也不妥当,毕竟用户并未主动同意采用这种方式接受消息。另外Category:不接受消息发送似乎是拒绝所有的发送,而不能只拒绝某类活动、某类消息的发送--百無一用是書生 () 2016年3月4日 (五) 02:12 (UTC)
@Shizhao:的確,我忘了MMS要使用特殊格式,謝謝您的提醒。不過我覺得像是WP:DC/IL這類未按照特殊格式的用戶發送列表,未來是可以將其改為MMS接受的格式(像是新建立一個[[WP:DC/IL/<發送列表>]],並將新的用戶名單包含引用至WP:DC/IL,以方便檢視。)而如果對「用戶未主動同意採用此方式發送」有疑慮的話,我覺得可以通知這些用戶們,並說明:「動員令邀請函未來將會使用MMS發送」。如果用戶同意採用MMS發送,則請他們在新建立的MMS格式發送列表內,加入自己的名字,並在將其從原本的列表中移除。如果不同意或仍未回覆的話,則未來在發送動員令邀請時,則對這些用戶維持原本手動的發送方式。而如果有新的用戶想要加入到邀請名單,則請他們加入到MMS格式的名單內,並說明「加入至此名單內,則代表您同意使用MMS發送動員令邀請給您」之類的語句。至於Category:不接受消息发送這個分類,的確會擋掉所有使用MMS發送的訊息,不過要過濾掉特定活動的訊息,方法要再研究。不過我覺得如果是在動員令結束後,主持人即可以用MMS發送給參與者各項通知,而不需要參與者同意才能發送,或者是在報名時加註說明字樣(像上面舉的例子)。--Bowleerin留言) 2016年3月5日 (六) 01:47 (UTC)
(+)支持。另外,我记得作猫先生的机器人好像有这个功能?--Stang 16 2016年3月4日 (五) 15:10 (UTC)
@Cosine02:要請他一起來討論嗎?--Bowleerin留言) 2016年3月5日 (六) 01:47 (UTC)

整理一下上方討論[编辑]

@和平奮鬥救地球ShizhaoAntigngTemp3600小躍@GqqnbWalter GrassrootLiaon98LnnocentiusJimmy Xu@BluedeckCosine02Lt2818KuailongCarrotkit:(如有疏漏,請見諒。)我先將上方所討論的要點列出來,方便進行討論:

  1. 目前社群大致上支持單獨設立MMS權限。
  2. MMS權限分為「臨時」(例如動員令主持人)與「長期」(例如《維基人》負責人)。「臨時」權限將於活動結束後收回,而「長期」權限則不收回。
  3. MMS權限申請,可以比照現行巡查員、回退員、或AWB使用權的申請方式。而在申請權限時,應依照WP:大量訊息發送者的規範申請。
  4. 發送訊息時,應事先建立一份適當的用戶列表,而用戶需同意此訊息由大量訊息發送功能發送
以上,如有缺漏,還望各位提出,也希望各位發表意見。--Bowleerin留言) 2016年3月5日 (六) 12:54 (UTC)
個人覺得「欲發送的訊息」可大致分為三類:「通知」、「邀請」、「刊物」。
  • 通知:發送給活動參與者。例如:動員令主持人發送「完成動員令通知」給已完成動員令的參與用戶、亞洲月主持人發送感謝參與訊息及亞洲月星章等。
  • 邀請:發送給某些「可能參與」某項活動的用戶,邀請其參與該項活動。如果該用戶表示不願再接收到這些訊息,則未來便不發送邀請訊息給該用戶。例如:發送「動員令邀請」給曾參與動員令的用戶,如果該用戶不願再收到,則在WP:DC/IL的黑名單內標注其用戶名,未來便不發給其動員令邀請。
  • 刊物:定期發送給訂閱戶的刊物。例如:在《維基人》出刊時,發送刊物給Wikipedia:《维基人》/机器人订阅列表上的用戶。
大致如上面所述。我覺得「通知」類的訊息,該項活動負責人可以在活動期間直接發送活動相關通知,不需事先徵得用戶同意。(有一種例外情形是:有用戶在討論頁加入了Category:不接受消息发送以至於無法送達,則再請活動負責人以其他方式解決。)「刊物」則只會發給有訂閱的用戶。「邀請」類則可以發給「可能」參與某項活動的用戶們,像是之前Walter Grassroot君發送給一些有參與過動員令的用戶們動員令邀請。
WP:MMS已完成翻譯,歡迎查看。--Bowleerin留言) 2016年3月5日 (六) 12:54 (UTC)
  • (+)支持。- 和平、奮鬥、救地球!於 2016年3月6日 (日) 12:04 (UTC)
  • (+)支持,我是觉得从技术方面可以通过BOT + AWB直接实现,设置这样的权限是否重复?我不太清楚;但的确从效率上快速很多,也简易很多。但是这样的功能是对维基没有坏处的,至少是积极地在促进信息交流和条目的撰写。--Walter Grassroot () 2016年3月6日 (日) 13:16 (UTC)
  • (+)支持--Temp3600留言) 2016年3月6日 (日) 15:20 (UTC)
  • (+)支持,沒什麼壞處。Innocentius留言) 2016年3月6日 (日) 15:28 (UTC)
  • "我覺得「通知」類的訊息,該項活動負責人可以在活動期間直接發送活動相關通知,不需事先徵得用戶同意。"这一点不同意--百無一用是書生 () 2016年3月7日 (一) 01:29 (UTC)
    • @Shizhao:我在上方留言所指的「通知」,是指發送類似{{DC13/done}}之類的通知訊息給有參與、且貢獻也達到完成動員令標準的用戶。因為用戶有參與這項活動,其貢獻也合乎標準,所以才發送給他。像這類「在活動期間所發送的活動相關通知」,我覺得是不需事先徵得用戶同意,才能發送的。像是Special:diff/37727841或是Special:Diff/37274575這種。--Bowleerin留言) 2016年3月7日 (一) 05:09 (UTC)
      • 这一类通知同样也应该是用户主动订阅后才能发送。如果没订阅发送的话,不应该用MMS功能,而应该手工发送--百無一用是書生 () 2016年3月8日 (二) 02:19 (UTC)
        • 手动发送如果是发送同样内容到同样一组用户的话我不觉得人为制造麻烦有什么意义。唯一一点好处是刚开始发几个自己/被别人发现问题后可以及时停止或修改,避免影响更多用户。Liangent留言 2016年3月8日 (二) 08:45 (UTC)
          • 另外需要用户主动订阅我没意见,可以把订阅消息直接作为参加动员令的一个步骤,或由用户决定“我不需要通知而将自行查看公告板”,但没必要因此给主持人增加不必要的工作量。Liangent留言 2016年3月8日 (二) 08:47 (UTC)
            • 难道这个讨论的目的就是为动员令而已?!--百無一用是書生 () 2016年3月9日 (三) 02:40 (UTC)
              • @shizhao:我覺得此討論適用於各種類似的活動(像是亞洲月等等),皆可適用。在這邊是以動員令當作範例(因為動員令是本地的活動,而且剛好有這個模板作為範例,所以舉動員令作為例子)。--Bowleerin留言) 2016年3月12日 (六) 13:03 (UTC)
  • (+)支持。--喜歡用IRCCarrotkit 2016年3月7日 (一) 10:01 (UTC)
  • (!)意見用户必须明确同意才能接受群发消息,比如默认opt out,我不要骚扰电话。--Gqqnb留言) 2016年3月8日 (二) 00:49 (UTC)
這在申請參加動員令時一併寫上就行了。--Temp3600留言) 2016年3月8日 (二) 14:06 (UTC)
@Gqqnb:您可以見上方這些我的回覆,我就不在這邊贅述了。不過如果要預設opt out的話,就會變成上面@Bluedeck君說的狀況。不過如果用戶仍不希望收到所有由此功能所發送的訊息,仍然可以在用戶討論頁加入Category:不接受消息发送來排除這些大量訊息。--Bowleerin留言) 2016年3月12日 (六) 13:03 (UTC)
@Bowleerin:是否需要将WP:MMS提升为方针?--Stang 2016年3月17日 (四) 07:08 (UTC)
(~)補充同时,就权限来讲,我希望给大量讯息发送者添加如下权限:删除自己的账户的用户组:大量讯息发送者,这样方便不需要的时候自动解权。--Stang 2016年3月18日 (五) 15:58 (UTC)
@Stang:我覺得可以將WP:MMS提升成為方針,但需要找時間另外開一新討論串討論。即是:先設立此權限後,再接著對WP:MMS的內文進行詳細的檢閱及修正,最後提升為方針。而在修訂方針期間,假若真的有人需要此權限的話而提出申請的話,則先暫時按照WP:MMS作為參考,但是相對的,審查時需嚴格把關,避免造成嚴重影響。而讓擁有MMS權限的用戶可以自己解除自己的權限,我覺得是個好想法,Facebook like thumb.png。但這要看看技術上是否可行(那麼授權時要同時授予兩個權限)。但如果真的遇到用戶遲遲沒有卸權(或忘了這件事),那麼其他人就要提報解除權限,可能會有點尷尬……(當然希望這不要發生)--Bowleerin留言) 2016年3月19日 (六) 11:06 (UTC)
已知技術上可行,故(+)支持上述提案。--Bowleerin留言) 2016年3月19日 (六) 12:56 (UTC)



看来社群已初步达成共识,设立MMS用户组。现进行公示,然后报到phab,如有意见请速提出。--Stang 2016年3月21日 (一) 02:10 (UTC)
(~)補充:@Stang:您上面指的是mw:Manual:$wgGroupsRemoveFromSelf這個吧?(就像是:在自己的帳號中移除的一個群組:大量訊息發送者這樣。)--Bowleerin留言) 2016年3月21日 (一) 05:14 (UTC)
我指设立MMS用户组,且给予他们“使用大量讯息”和“删除自己的账户的用户组:大量讯息发送者”的权限。--Stang 2016年3月22日 (二) 10:59 (UTC)
@Stang:好吧,我是指您上面(~)補充裡說到的「就權限來講…(恕刪)」這句在MediaWiki對應到的一些參數, 囧rz...。不過這樣也好,同時把上分隔線上面的討論內容做初步總結了。--Bowleerin留言) 2016年3月22日 (二) 12:07 (UTC)
phab:T130814已提交。--Stang 2016年3月24日 (四) 08:54 (UTC)
gerrit:279365已修改完成,待伺服器更新後,即可正式實行。--Bowleerin留言) 2016年3月24日 (四) 15:19 (UTC)

WP:MMS提升为指引[编辑]

等待代码部署的时间里,我们不如逐字逐句的研究将WP:MMS提升为方针的建议。希望大家给予补充。--Stang 2016年3月24日 (四) 12:54 (UTC)

  • (!)意見,感覺仍有小部分內容沒寫完,有待完善。--就是他 ☞ Q 「祝考試順利」「有事請留言」 2016年3月24日 (四) 17:37 (UTC)
  • 近期我修了一下語句不通順之處,目前大致上沒有問題,故(+)支持提升為方針指引。過若仍有有漏網之魚,也請各位踴躍提出,謝謝。--Bowleerin留言) 2016年3月25日 (五) 14:38 (UTC)
  • (+)支持:大致上沒什麼樣的問題。--Engle躍✈‎安裝文字動畫效果】 2016年3月26日 (六) 01:52 (UTC)
  • 另外提醒一下@ShizhaoMediaWiki:Group-massmessage-sender的內容應該寫錯了,請管理員協助修復為「大量訊息發送者」,謝謝!--Bowleerin留言) 2016年3月26日 (六) 03:15 (UTC)
  • (!)意見我认为不应该是方针,而是指引。方针与指引都是相当等级的偏硬性规定,而方针更像是一种政策性的规定,而指引是教导用户如何使用的说明,所以应该是使用为指引。——路过围观的Sakamotosan 2016年3月26日 (六) 05:31 (UTC)
  • (!)意見(▲)同上Cwek,論內容與性質當為「指引」--凡夫2015留言) 2016年3月29日 (二) 09:00 (UTC)
    • (?)疑問,@cwekJesus estw:那WP:NPPWP:ROLL呢?这些都是一些指导性的东西,但还是方针而非指引。--Stang c 2016年3月29日 (二) 12:17 (UTC)
(:)回應,既往不咎。但始终坚持并建议定位为指引,而非更高要求的方针。方针带有更强的强制性,就像NPP和ROLLBACK本身就是从管理员的权限中分离出来,而且具有更麻烦的破坏性,需要对拥有者有一定要求的审定,所以我认为当时定义为方针的要求。也可能与制定时的社群水平有关。——路过围观的Sakamotosan 2016年3月29日 (二) 13:29 (UTC)
(:)回應,主張同上,僅依當前草案而論,個人觀點如「傳令兵、傳令官、外交部(國務院)發言人」區分,或說「法」(行政命令、法律、憲法),層次及強制性都有所不同(不是法學緒論課程),因此主張為「指引」即可。--凡夫2015留言) 2016年3月30日 (三) 08:13 (UTC)
如此的话,我同意。--Stang c 2016年3月31日 (四) 06:29 (UTC)
那麼我更改一下標題為:〈提升WP:MMS為指引〉,並改為(+)支持該頁面提升為指引。同時邀請其他人一同參與討論:@和平奮鬥救地球ShizhaoAntigngTemp3600小躍回复模板最多支持5个用户。如果需要超过5个,必须使用多个模板。模板用法見於Template:Reply to。另外通知一下@小躍,因為目前標題已經更改,故在此通知您。--Bowleerin留言) 2016年3月31日 (四) 12:57 (UTC)
因{{ping}}模板已修復完成,故在此重新Ping一次某些可能沒被Ping到的用戶,並多邀請一些人一同參與:@James970028ShizhaoAntigngTemp3600霧島聖@GqqnbWalter GrassrootLiaon98NbfreehTechyan@BluedeckJasonzhuocnLt2818KuailongLiangent:@QinyongrCwek。--Bowleerin留言) 2016年4月1日 (五) 15:56 (UTC)
(+)支持。--Stang c 2016年3月31日 (四) 13:06 (UTC)
(+)同意升為指引。-和平、奮鬥、救地球!於 2016年3月31日 (四) 13:11 (UTC)
(+)同意升為指引。--凡夫2015留言) 2016年3月31日 (四) 13:52 (UTC)
(+)支持。--Innocentius留言) 2016年3月31日 (四) 22:09 (UTC)
(+)支持。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月2日 (六) 01:45 (UTC)

  • 結論:已達成共識,提升WP:MMS為指引完成。--Bowleerin留言) 2016年4月3日 (日) 11:48 (UTC)

MediaWiki:Group-massmessage-sender[编辑]

抱歉刚想起来这个事。当时上报phab后,那边的人给了本地化的建议,就是MediaWiki:Group-massmessage-sender中的命名问题。当前Shizhao创建的页面内容为“群发消息者”,但似乎未取得社群的共识。希望管理人员先删除此页面,之后有了共识再更改。而且,应该更改的是MediaWiki:Group-massmessage-sender/zh吧?目前对于命名,有如下方案:

  1. 群发消息者,简明,但Bowleerin认为我觉得使用“大量讯息发送者”即可,而此权限也有一简称:“MMS”(MassMessage Sender)。就像是“自动维基浏览器使用权”可以简称为“AWB使用权”一样。--Bowleerin(留言) 2016年3月3日 (四) 12:52 (UTC)
  2. 大量讯息发送者,见Bowleerin君的提议;
  3. 大量消息发送者,见Transwiki.net 当前的翻译;
  4. 大量信息发送者,见Qinyongr君的提议。

恳请达成共识。--Stang c 2016年3月31日 (四) 13:06 (UTC)

(!)意見大量信息发送者可能對於簡體用戶更為的順口。--就是他 ☞ Q 「祝考試順利」「有事請留言」 2016年3月31日 (四) 13:10 (UTC)
(-)反对「群發消息者」,「群發」這個詞尤其是在大陸可能不好。(!)意見:「消息」和「訊息」還需要進一步區分。-- 給我留言 「歡迎加入 #cvn-zh-scan Qinyongr 2016年4月14日 (四) 11:35 (UTC)
(!)意見:「大量-{zh-hans:信;zh-hant:訊}-息發送者」。-和平、奮鬥、救地球!於 2016年3月31日 (四) 13:16 (UTC)
抱歉,Transwiki那边名称记错了。--Stang c 2016年3月31日 (四) 13:17 (UTC)
(!)意見,訊息群發員?和巡查員和回退員類似的思路...--Innocentius留言) 2016年3月31日 (四) 22:11 (UTC)
群发多顺口啊。。--Gqqnb留言) 2016年4月1日 (五) 04:43 (UTC)
+1 --Engle躍名字招牌快來買會動不用錢】 2016年4月1日 (五) 04:46 (UTC)
(!)意見:「-{zh-hans:信;zh-hant:訊}-息群發員」。--219.84.185.103留言) 2016年4月1日 (五) 12:39 (UTC)
(+)支持和平奮鬥救地球的意見,使用「大量-{zh-hans:信;zh-hant:訊}-息發送者」。另外,是修改MediaWiki:Group-massmessage-sender/zh沒錯……--Bowleerin留言) 2016年4月1日 (五) 13:23 (UTC)
我不确定-{}-这种东西能在Mediawiki空间用吗?比较(+)支持大量信息发送者。--Stang c 2016年4月5日 (二) 12:09 (UTC)
不能用,MediaWiki消息不进行语言变种转换,但是可以用/zh/zh-hans等等语言子页面来实现手动繁简转换--Nbdd0121留言) 2016年4月5日 (二) 16:30 (UTC)
(+)支持群发消息者,读起来顺口。#ForeverLove(给我留言)凡人丶 你一定要好好的 不想让自己用户页被删除的办法 2016年4月5日 (二) 13:24 (UTC)
(+)支持 群发消息者--Nbdd0121留言) 2016年4月5日 (二) 16:30 (UTC)
(+)支持:群发消息者--南瓜留言 | 贡献) 2016年4月5日 (二) 19:53 (UTC)
(+)支持:群发消息者--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月8日 (五) 06:49 (UTC)
(+)支持,「大量讯息发送者」。不反對「群发消息者」,希望各有各用,港澳一組,中國大陸一組。--Iflwlou [ M {  2016年4月15日 (五) 14:43 (UTC)
(!)意見:就zh-hant的用戶來說,這種情形使用「訊息」居多,我認為可以分別編輯語言子頁面進行轉換,然後將該字詞加入全域字詞轉換,不知道各位覺的如何?--Bowleerin留言) 2016年4月13日 (三) 11:31 (UTC)
(!)意見,我希望不同地域使用不同字眼,中國大陸或許習慣使用「群发」這種精簡字眼,但是作為香港人,不太習慣,我希望不是一次過要求全體使用一組字眼,而是不同地方的維基人使用不同組的字眼,而且技術上也做得到。--Iflwlou [ M {  2016年4月15日 (五) 14:38 (UTC)
(+)支持大量消息发送者,繁体区采用大量訊息發送者。亦支持群发消息者。但是更希望中文维基和translatewiki统一。--1=0欢迎河北维基人加入QQ群331736133 2016年4月19日 (二) 16:36 (UTC)

:(!)意見@StangAlexander Misel:如果大多數香港人因為不習慣而想要另外一種翻譯,建議Hans:群发消息者,zh-tw也是群發消息者,zh-hk獨立設置。--Jasonzhuocn留言) 2016年4月28日 (四) 12:49 (UTC)--Jasonzhuocn留言) 2016年4月28日 (四) 14:15 (UTC)

(!)意見,我比較支持命名為「大量-{zh-hans:信;zh-hant:訊}-息發送者」。一來,「信息」與「訊息」讀音相近,有助於在表達上統整,將兩者之間的差異降低,同時也考慮到了各地用詞的差異。--Bowleerin留言) 2016年4月28日 (四) 13:01 (UTC)
意見(▲)同上。-和平、奮鬥、救地球!留言DC14討論於 2016年4月28日 (四) 13:03 (UTC)

(意见请在线上提出,谢谢合作。)

看来已初步达成共识:使用“群发消息者”作为群组名。现进行公示,7日后如无其他意见,请管理员更新MediaWiki:Group-massmessage-sender/zh。--Stang c 2016年4月11日 (一) 02:53 (UTC)
撤销,念及“希望不同地方的维基人使用不同组的字眼”。@Liangent:您的机器人可以实现不对特定页面进行转换吗?如果可以,我(+)贊成Hans:群发消息者,Hant:大量讯息发送者。--Stang c 2016年4月19日 (二) 10:09 (UTC)

空格[编辑]

在中文維基格式手冊裏,空格一節寫出,「在中文語境內,文字之間應該不留空格。」請問這是否只是指中文與中文之間?在中文與英文之間,在中文與數學符號之間,在中文與數學方程之間,在標點符號與中文之間,是否可以留空格?在英文維基裏,對於空格的置入沒有做出限制。從英文維基輸入的模板與數學方程裏,都存在著很多空格。我覺得在原始碼內適當地置入空格,可以幫助檢視與維持;在頁面裏適當地顯示空格,也可以幫助閱讀、美化頁面。我們是否可以賦予空格一些它可以承擔的功能?請大家發表寶貴意見,達成共識,謝謝!--老陳留言) 2016年3月22日 (二) 05:58 (UTC)

  • (-)反对反對中文與英文之間加入空格,應維持原本的格式,格式統一整齊才是重點。如果以個人感官來說,我覺得加了這些空格反而顯得版面混亂,所以這是個人審美與習慣問題,加空格並沒有絕對的幫助。--泅水大象訐譙☎ 2016年3月22日 (二) 06:39 (UTC)
  • (!)意見,這很明顯是講中文字與中文字之間,中文文句的文法裏本來就沒有空格這回事,把一句長句作適當的區分是用逗號而不是空格,用空格違反了標準文法。而中文以外的部份,則應以常識來決定各個案例與特例是否應該加入,反而不應該在手冊裏做提議統一要不要加空格。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月22日 (二) 06:51 (UTC)
    • 他的問題應該是針對中文與英文之間的介面部分,至於標點符號與中文之間的空格就更不可行了。--泅水大象訐譙☎ 2016年3月22日 (二) 09:57 (UTC)
      • 他問:「請問這是否只是指中文與中文之間?」我答:「這很明顯是講中文字與中文字之間」。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月22日 (二) 10:00 (UTC)
        • 哈,誤會誤會,原來你講的是他針對格式規則的原發問,而我講的是他的主張,雞同鴨講了。--泅水大象訐譙☎ 2016年3月22日 (二) 10:28 (UTC)
  • 首先中文文法不需要在字词之间添加空格;其次由于模板等的字段的空格在被解释器处理时会被过滤掉,所以空格才不会显现。——路过围观的Sakamotosan 2016年3月22日 (二) 07:15 (UTC)
  • 量子諧振子為例,User:Πrate的傀儡用自動化工具刪掉半形空格後,在「一個質量為m的粒子」就已經有字體輕微重疊的現象(m是斜體),同一條目的其它因為刪掉空格而影響閱讀的例子就不用逐一列出了,眼見為實,尤其是當預設字體為「新細明體」時。--Mewaqua留言) 2016年3月22日 (二) 10:24 (UTC)
    • 所以重點應該是為何內文中要出現斜體,而不是空格的問題吧?之前已經有過其他討論,認為英文維基中對於拉丁文或專有名詞所做的斜體處理,不該直接沿用到中文維基。還有,字間距我記得可以利用CSS的方式調整,每個人都有各自習慣的版面安排。--泅水大象訐譙☎ 2016年3月22日 (二) 10:32 (UTC)
      • 我無記錯的話,數學代數裏正常字體和斜體是有不同意思的:正常字體表示常數和函數名稱,斜體字母則表示變數,例如:cos x;而「一個質量為m的粒子」的m應該是變數所以用斜體,不過在我這裏「m」和「的」之間沒有重疊,我這邊配置了拉丁字母用Arial而中文用XP版新細明體。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月22日 (二) 12:13 (UTC)
        • 找到一些會造成顯示錯誤的例子:X粒子、Y粒子、Z粒子、X0粒子、Y0粒子、Z0粒子。英文維基並沒有對空格的置入做出甚麼限制,我們為甚麼要過度規定空格的置入?--老陳留言) 2016年3月23日 (三) 05:35 (UTC)
          • 對於這種情況其實並沒有建議要用抑或不要用空格,還是一句:請按個別情況用常識決定是否加空格。而我這邊顯示「XYZ」和「粒/0」之間衹是少許的緊迫,不覺得對閱讀有很大的妨礙。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月23日 (三) 06:17 (UTC)
老陳君提的例子在我的畫面上完全正常一點都沒有重疊,所以問題的根源還是自己瀏覽器字型設定或CSS造成的。如果真的有很嚴重的顯示問題疑慮時彈性的運用空格或許可以接受,但原開題者顯然是想要求全面性的開放,這問題就嚴重了:如果他覺得空格比較美觀、我覺得空格不美觀,所以不同的人編輯時有不同的格式,搞得整個中文維基格式不統一亂七八糟,更嚴重時還可能因為不同審美與習慣的用戶編輯同一文章時反覆新增或刪除空格導致編輯戰,各位還覺得不規定一個格式原則是好事嗎?還有,英文原本就有標準的空格使用格式,所以根本不需特別在維基百科中規範,但中文與英文字之間的介面並不在標準中文的格式規範中,所以我們才會需要在這裡提出討論,二者狀況不全然相同不該直接類比。--泅水大象訐譙☎ 2016年3月23日 (三) 06:21 (UTC)
敝人還是覺得不應該有標準,單是我本人加不加空格就已經很多不同的處理方法,比如說:如果中文字後面接着一個英文單字的話,我通常不會空,但是如果是接一組英文片語或句子的話,則通常會有空……還有許多層出不窮的情況令我施加變化,許多時候甚至要看正文表述了甚麼內容才得以決定值不值得加空格。所以還是維持現有的自由度,統一建議我完全也不見得是好事,尤其是某一條目用不用空格的做法又未必適合用到另一條目的時候。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月23日 (三) 06:42 (UTC)
那也是建立在電箱君大體上是瞭解中文維基基本的格式規則、只是在必要時略作調整,跟整個不訂定格式準則隨各人喜好發揮是兩回事。中文維基有些軍事或汽車相關的條目,當初編輯的用戶是直接拿英文維基條目的內容copy & paste過來之後逐字中譯,所以會留下跟英文一樣的字間空格等「遺跡」,整個條目看起來就是像狗啃過一樣東一塊白西一塊缺,完全無法體會其中的美感何在,只給人一種整體品質低落的印象。中文維基還是應該有一個基本的格式規範定義大部分情況下的版面撰寫方式,再保留必要時個案調整或討論的空間,而不是完全不設格式標準,這是完全不同的兩種狀況。--泅水大象訐譙☎ 2016年3月23日 (三) 06:58 (UTC)
定下建議理應是衹有很少量的例外情況,但是關鍵是在這個空格的問題上無論我建議要有空格還是不要有空格,我預視到都會出現大量的例外,即不存在所謂的大部分情況都適用的方法,所以就算訂定了也不會有意思。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月23日 (三) 07:11 (UTC)
我倒是抱持著不太一樣的看法,我認為如果有訂定原則但允許在需要時例外,乍看之下似乎與沒訂定原則一樣,但實際上意義不同。因為這表示若想要有例外就必須要提供必要性的證明,如無特殊必要還是要回歸標準格式,萬一有天真的有兩名用戶因為要不要加空格而發生爭議時,我們就可以根據該空格的添加是否有功能上的必要性來作為衡量的依據,而不會因為無規則來源可供判斷而陷入意氣之爭。別說我杞人憂天這時就在思考編輯戰之類的情況,事實是多年下來的經驗告訴我們就是這種事最容易導致編輯戰,所以我這是在未雨綢繆。--泅水大象訐譙☎ 2016年3月23日 (三) 07:32 (UTC)

英文維基對於空格置入的規則相當具有彈性,甚至多種空格置入格式可以存在於同一條目,或許這是我們可以借鏡之處: [1]

In normal text, never put a space before a comma, a semicolon, a colon, or a terminal punctuation mark. Put a space after these, unless they end a paragraph or are followed by a closing parenthesis, quotation mark, or similar. The number of spaces following the terminal punctuation of a sentence in the wiki markup makes no difference on Wikipedia; the MediaWiki software condenses any number of spaces to just one when rendering the page. For this reason, editors may use any spacing style they prefer on Wikipedia. Multiple spacing styles may coexist in the same article.

一般而言,原始碼的空格顯示問題可以由MediaWiki軟件處理,如果MediaWiki軟件可以處理這問題,為什麼要強硬規定編輯者怎樣置入空格?在原始碼內適當地置入空格可以幫助閱讀與維持原始碼,除去這些空格,則原始碼會變得像古文一般地難讀難懂。我們應該幫助編輯者進行編譯的工作,而不是設定規則要求他們做一些「軟件可以做的工作」。--老陳留言) 2016年3月23日 (三) 22:36 (UTC)

我看完上面那段規則後怎覺得英文版的空格輸入規則很嚴格?裡面用了「never」「unless」這種語氣很強烈的字眼,明確規定分號、逗號、句號前面「絕對」不能加空格,這些符號後面除非緊接括號括號否則「一定」要加空格(原句用動詞原形「Put」起頭,表示是強命令句型)。最後面那段是在說因為系統會自動壓縮空格,因此用戶可以自行選擇自己喜歡的空格輸入格式(原文是「Multiple spacing "styles"」),言下之意您為了編輯便利輸入單格的空格、雙格的空格或多格的空格顯示結果都一樣,但是輸入空格的「位置」可是有嚴格規定的,並非老陳君所想像與主張,希望能由用戶自行選擇輸入空格「位置」的作法。所以,您舉例英文維基的規則其實正好否決了您自己的提案。--泅水大象訐譙☎ 2016年3月24日 (四) 03:25 (UTC)
謝謝您的關注與意見!希望您翻譯英文時,務必要仔細嚴謹,不能斷章取義:
  1. In normal text(在正常文句裏):這不包括特別案例,例如,模板內的原始碼、數學公式與正常文句之間的界面等等。英文維基沒有對這些特別案例做出規定。
  2. Multiple spacing styles may coexist in the same article(多種空格置入格式可以共存於同一篇文章):請注意到英文單字「coexist」。--老陳留言) 2016年3月24日 (四) 05:34 (UTC)
斷章取義的是您吧?
1. 原文是說in normal text沒錯,但是它並沒有說「模板內的原始碼、數學公式與正常文句之間的界面」可以加空格,那是您自己單方面的衍生解釋,能不能被接受尚有討論空間。
2. coexist的主詞是「spacing styles」(空格的格式),也就是我提過同一條目內空格是要打單字元、雙字元或多字元都沒差,因為系統會自動壓縮調整,但是您的主張其實是在討論空格安插的「位置」,請問原文中何處有說各種不同的安插位置規則可以coexist的?
希望您翻譯英文時,也務必要仔細嚴謹,不該把自己的主張混入對規則的翻譯中。--泅水大象訐譙☎ 2016年3月24日 (四) 06:13 (UTC)
謝謝提醒!我覺得「在中文語境內,文字之間應該不留空格」這句子寫得不夠明確,很容易引起不同的詮釋。因此,我提議改寫為「在中文語境內,中文文字與中文文字之間應該不留空格」。其他論題可以留待以後商討。希望獲得大家共識,不知道您覺得可否這樣改寫?--老陳留言) 2016年3月25日 (五) 05:45 (UTC)
不可以,如果這樣改寫等於變相允許中文與英文字之間可留空格(所謂中文「語境」,就表示包含在中文文章中插入英文字的情況,但排除整句都是外文內容的情況,原規定其實寫得很清楚)。如果要改,還是應該先獲得社群共識後再依照討論結果修正。--泅水大象訐譙☎ 2016年3月25日 (五) 07:16 (UTC)
按照您的說法,為了避免爭議,我提議將這句子改寫為「在中文句子內,中文文字與中文文字之間應該不留空格」。--老陳留言) 2016年3月26日 (六) 14:10 (UTC)
(:)回應原文中的中文「語境」原本就是泛指以中文作為主體,只是局部插入外文字的情況,包括中文與中文字之間,也包含中文與外文字體之間,僅有全段皆為非中文(也就是外文語境)的狀態下允許插入空格。所以,您這樣的狹義定義乍看之下好像是要把規定解釋清楚,但實際上根本是暗渡陳倉把您的主張混入規則中,是很不妥的作法。如果您想要自己的主張被實現就請等討論流程完成之後再說,但很顯然一路看下來支持您主張的用戶僅屬少數。--泅水大象訐譙☎ 2016年3月28日 (一) 05:26 (UTC)
從2010年至今,與User:Πrate和其傀儡為了一個空格而發生爭執的用戶顯然不是少數(例如User:ArikamaI),Wikipedia:五大支柱:「維基百科不墨守成規: 維基百科制定有方針與指引,但並非板上釘釘不可更改,其內容和解釋可以逐漸發展完善。它所蘊含的原則和精神比字面措辭更為重要,並且有時為了改善維基百科允許有例外。」--Mewaqua留言) 2016年3月28日 (一) 05:38 (UTC)
又加一個例子,User:Πrate的傀儡在眾多條目的參考文獻裡刪掉新聞標題中用作分隔句子的space(例如聖人瀑布,如把「開放聖人瀑布 溪山里民疾呼」改成「開放聖人瀑布溪山里民疾呼」),增加閱讀上的不便。--Mewaqua留言) 2016年3月28日 (一) 05:53 (UTC)
參考文獻非主文本就不在格式手冊規定的範圍,直接依照文獻來源原本的格式也屬合理。M君舉的例子正證明了相關的格式規則還是要訂以避免編輯戰的可能,但規則若有不恰當之處隨時都可提出檢討修改,或在必要時彈性調整,但給編輯用戶一個基本的遵循依歸還是很重要的。--泅水大象訐譙☎ 2016年3月28日 (一) 06:11 (UTC)
從英文維基輸入至中文維基的參考文獻與模板,其內部遍布了很多空格,這是為了使得原始碼易讀易懂,MediaWiki軟件會自動處理這些空格。請問您是否贊成允許空格在參考文獻內存在?請問您是否贊成允許空格在模板內存在?--老陳留言) 2016年3月30日 (三) 00:33 (UTC)
這跟英文維基無關,系統處理模版時原本就會忽略掉文字(無論中文英文)前後的空格,但不會忽略文字與文字間的空格,但是閣下明明在講的就是在文字與文字(例如中文與英文字母間的介面)插入空格的主張,且明明討論的就是主文部分,為何老是拿不相干的事情來混淆視聽?--泅水大象訐譙☎ 2016年3月30日 (三) 06:36 (UTC)
一個條目不只是只有主文部分,它還包括條目名、主文、標題、參考文獻、模板等等。所以,您不反對在參考文獻、模板內的空格可以存在。--老陳留言) 2016年3月31日 (四) 22:15 (UTC)
不會實際在畫面中顯示出效果的空格我不在意,參考文獻中的title欄位原本就是用來顯示原文,因此比照原文格式也是合理,其他部分請遵守格式守則。--泅水大象訐譙☎ 2016年4月1日 (五) 02:51 (UTC)
很高興能夠達成共識:-)!--老陳留言) 2016年4月1日 (五) 22:34 (UTC)
  • (-)反对中文與英文之間加入空格。--喜歡用IRCCarrotkit 2016年3月26日 (六) 12:39 (UTC)
  • 謝謝表達您的意見!尚未到投票階段。是否可以給出反對理由?--老陳留言) 2016年3月27日 (日) 22:11 (UTC)
  • (-)反对在任何地方加不必要的空格,包括中英文之间。--Antigng留言) 2016年3月27日 (日) 06:29 (UTC)
  • 謝謝表達您的意見!尚未到投票階段。可否詳細指出,甚麼是必要,甚麼是不必要?--老陳留言) 2016年3月27日 (日) 22:11 (UTC)

从来没考虑过这个问题,于是看了一下我之前写的条目,确实没有在中英文之间加空格的情况。这应该是我潜意识下的做法。实际上Micrososft Word这类软件的做法是自动在中英文之间留白(自动检测,然后空出间距,不必手动添加空格)。这应该是CSS/JS就能做到的。斜体的情况下,Y0的例子下,我的显示重叠了,看起来几乎像是Ytheta(字体:Yu Mincho)。我觉得在这种情况下可以加上空格。Bluedeck 2016年3月27日 (日) 23:54 (UTC)

那为什么斜体后面就不能用JS/CSS加……--Jimmy Xu 2016年3月28日 (一) 00:41 (UTC)
很有趣的是「Y0」這個狀況並不是該利用空格修正格式的好場合,因為如果在斜體字後方加空格來修正,雖然原本有字體重疊問題的用戶看到的畫面正常了,但原本顯示很正常的用戶,卻反而會看到「Y」跟「0」之間被明顯拉開看起來不太像指數符號的情況。若要修正這問題,使用CSS調整恐怕才是治本的方法。--泅水大象訐譙☎ 2016年3月29日 (二) 04:19 (UTC)
{{Lang|en|''Y''<sup>0</sup>}},顯示為Y0。--Mewaqua留言) 2016年3月30日 (三) 02:09 (UTC)
所以意思是說其實斜體後面的文字重疊問題,用lang模版就能解決?(在我所使用的瀏覽器/字碼版本上有沒有加lang的顯示效果一模一樣,所以無法分辨)--泅水大象訐譙☎ 2016年3月30日 (三) 06:38 (UTC)
可是我這裡看這樣也會重疊?(雖然感覺沒那麼重疊,但是可能是因為文字較粗造成的錯覺)-和平、奮鬥、救地球!於 2016年3月31日 (四) 04:30 (UTC)
不就是说明了可以通过CSS(或者HTML标签渲染机制)来解决?{{lang}}只是将相应语句用带有lang属性的span包裹,然后让浏览器根据语言来推断字体库,有些字体库能支持斜体字符不覆盖,有些字体库不能。——路过围观的Sakamotosan 2016年4月1日 (五) 01:03 (UTC)
我的发言欠缺考虑,我同意Y0是不应使用空格拆分的。Bluedeck 2016年3月31日 (四) 17:26 (UTC)
如果中文和英文之间要增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。如果中文和数字之间要增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。如果学习User:Cdip150的做法,中文和英文短语之间不加间距,和英文句子之间增加间距,则用JavaScript或CSS技术性解决,禁止人为在源代码级别加空格。--Gqqnb留言) 2016年4月1日 (五) 07:02 (UTC)
在下面的例子中,我没有在源代码里添加任何空格,CSS在实现中应为JavaScript所加:紧凑型中Condensed Text;疏散型中Scattered Text--Gqqnb留言) 2016年4月1日 (五) 07:09 (UTC)
很有意思的方法,讚!--老陳留言) 2016年4月2日 (六) 06:39 (UTC)
JavaScript與CSS技術屬電腦領域,只有電腦專家懂得怎樣正確操作這種高階技術,普通編輯者只能望洋興嘆,請問是否能夠給出一些普通編輯者能夠容易操作的方法?--老陳留言) 2016年4月3日 (日) 05:04 (UTC)
margin-right不太合适吧,这样源代码就很难看了,还不如一个空格美观。--Nbdd0121留言) 2016年4月5日 (二) 16:40 (UTC)
“CSS在实现中应为JavaScript所加”没有人需要在源代码里手工编写这些代码。--Gqqnb留言) 2016年4月9日 (六) 00:54 (UTC)
@Gqqnb(-)反对 JS会延后加载,这种方法不可避免的会出现页面闪一下。--Nbdd0121留言) 2016年4月9日 (六) 16:05 (UTC)
@Nbdd0121(-)反对,我不知道你对JavaScript或计算机科学的了解有多深,我不想说我计算机科学经历,但现在几乎没有网站不用js,技术问题就可以技术处理。不要一直动源代码的主意。--Gqqnb留言) 2016年4月10日 (日) 20:03 (UTC)
@Gqqnb(:)回應,我也不知道你对JavaScript或计算机科学的了解有多深,但你需要知道MediaWiki的JavaScript是通过ResourceLoader Queue延迟加载的。如果你要通过JavaScript来修改界面样式,那么不可避免的会出现闪烁。如果段落较长,修改margin或者letter-spacing的效应堆加起来甚至会影响整个页面的排版。--XYZ指示物留言) 2016年4月10日 (日) 20:38 (UTC)

(!)意見 我认为这件事需要分情况来看:如果英文是按照中文的语法作为一个名词插入在文中,这种时候应该不加空格;其他情况下,语法联系没有那么紧密的场合,是否添加空格就不需要管的那么严格。另外重叠的情况其实<math>可以很好的解决,可惜维基用的基于图片的<math>难免带来一点麻烦:Y^0--Nbdd0121留言) 2016年4月5日 (二) 16:40 (UTC)

(+)支持 个人认为对于纯文本编辑或者标记语言适当留白的做法,不论对于页面显示,还是源代码检视都有助于优化可读性,美观性。适合添加空格的场景如:中文与英文之间,中文与数字之间,英文与数字之间(不包括专有组合如奥迪 A8,AK47 等)建议这几种场景在边界两端加空格,遇到标点符号或句尾在单边加空格或不加。仅供参考:为什么你们就是不能加个空格呢? Pityonline留言) 2016年4月9日 (六) 01:41 (UTC)

感謝支持!在英文裏,空格扮演很重要的角色,在中文原始碼裏,我們也可以給予空格一些有助於可讀性、美觀性的功能,避免過度限制編輯者置入空格的行為。--老陳留言) 2016年4月9日 (六) 06:15 (UTC)
(+)同意 部分同意,不过如果只有一个单词的专有名词按照中文语法放在句子中,加上空格会不会让人感觉在强调一样?--Nbdd0121留言) 2016年4月9日 (六) 16:05 (UTC)
您提出了一個很好的問題!在維基百科裏,有幾萬個條目,其中,有些條目品質優良,但也有些條目品質粗劣,怎樣分辨優質的條目與劣質的條目,這是我們編譯者時常要面對的工作。我覺得格式手冊空格章節的規則有改良的必要,特別是在原始碼方面,所以提出討論,嘗試加以改良,希望能夠獲得共識。--老陳留言) 2016年4月10日 (日) 22:03 (UTC)
  • 對於“一个质量为m的粒子”,兩個用戶看到的結果不一樣
用戶1的瀏覽器的結果:一个质量为m的粒子
源代碼:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m''的粒子</span>
用戶2的瀏覽器的結果:一个质量为m的粒子
源代碼:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m''的粒子</span>
如果字母m前面加入空格
用戶1的瀏覽器的結果:一个质量为m 的粒子
源代碼:<span style="font-family:'微软雅黑',sans-serif">一个质量为''m'' 的粒子</span>
用戶2的瀏覽器的結果:一个质量为m 的粒子
源代碼:<span style="font-family:Arial,'新細明體',sans-serif">一个质量为''m'' 的粒子</span>
可以看出,“加入空格”給不同用戶帶來的影響不一
CSS letter-spacing我想應用在“m的”這部分文字,效果跟“加入空格”差不多,後者調整的單位是空格,前者的單位很小 - John doe 120留言) 2016年4月23日 (六) 08:26 (UTC)
  • 打開網頁[2],然後右鍵點擊“一个质量为m的粒子”,點擊“Inspect”...發現問題的起源是Vector screen styles...不多說了,下面的代碼從個人的vector.css複製,“預覽”按鈕好像有問題

/* 取代[https://phabricator.wikimedia.org/diffusion/SVN/browse/trunk/phase3/skins/vector/screen.css?view=markup]的font-family規則
   參考資料:[http://stackoverflow.com/questions/2436749/how-to-add-multiple-font-files-for-the-same-font] */
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    /* 部分瀏覽器不支持codepoint range,[https://developer.mozilla.org/en/docs/Web/CSS/@font-face/unicode-range#Browser_compatibility] */
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-style:italic;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-weight:bold;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@font-face {
    font-family: 'Ampersand';
    src: local('Arial');
    font-weight:bold;
    font-style:italic;
    unicode-range: U+2?,U+3?,U+4?,U+5?,U+6?,U+7?;
}
@media screen{
    body{
        /* Ampersand這名字沒有任何意思 */
        font-family:Ampersand,sans-serif;
    }
}

- John doe 120留言) 2016年4月26日 (二) 12:16 (UTC)

难道就没人会用LaTeX吗?[编辑]

这是X粒子、Y^0粒子、\Sigma^-粒子?--4Li 2016年4月30日 (六) 04:44 (UTC)

提議修改格式手冊中的空格章節[编辑]

從英文維基輸入至中文維基的參考文獻與模板,其內部遍布了很多空格,這是為了使得原始碼易讀易懂,MediaWiki軟件會自動處理這些空格,所以,按照泅水大象™ 、Mewaqua與我先前達成的共識,我提議,添加一條規則:

  • 在參考文獻、模板內可以保存適當數量的空格。

請大家投票與發表意見,謝謝!--老陳留言) 2016年4月2日 (六) 06:05 (UTC)

多餘,格式手冊針對空格本來就有這麼的規定:「如果官方宣佈的名稱內含有空格,以官方為準。」參考文獻標題是文獻的官方給的,所以它帶有空格本來就已經被允許。還有請不要把討論分開多個山頭,都不知應該在哪裏討論才好。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月2日 (六) 06:21 (UTC)
在格式手冊的空格章節裏表明,「在中文語境內,文字之間應該不留空格」。這規定意味著嚴格限制空格的存在,不只是在標題內而已。我不清楚您對這規定如何詮釋,但我覺得這規定並未給予編輯者足夠的詮釋空間。為了避免有些破壞者利用這規定進行大量刪除空格的無建設性編輯,並在其中夾雜著錯誤編輯,如在聖人瀑布裏的惡性編輯,所以才提議添加規則。關於在哪裏討論才好這問題,我不會堅持己見,請問應該在那裡討論較好?--老陳留言) 2016年4月3日 (日) 00:27 (UTC)
我仍然認為不需要添加,其實我上面說的話本身也有點多餘,因為我是假設該節適用於參考文獻的來跟您說,不過實際是不適用的,因為該節已經說了「在中文語境內」,但參考文獻本身就不是成句話,所以不算是「語境」,繼而如大象兄所說,根本不在格式手冊規定的範圍內。(討論的位置應該在#空格延續,而不是現在這裏另起爐灶)--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月3日 (日) 06:58 (UTC)
已移動討論位置。--老陳留言) 2016年4月4日 (一) 01:37 (UTC)
術語「中文語境」缺乏明確定義。是否應該對於術語「中文語境」給出明確定義?假若中文語境不包括參考文獻在內,那中文語境到底包括甚麼部分在內?--老陳留言) 2016年4月7日 (四) 05:25 (UTC)
聖人瀑布模板内的空格编辑,为非建设性编辑,应避免。“17 公尺”去除空格,符合格式手冊规定。民国纪年的替换我暂保留意见。参考资料里author、title去除空格不正确,这项属于严重错误。--Gqqnb留言) 2016年4月9日 (六) 01:02 (UTC)
按照您的說法,“17 公尺”前面與後面的空格都符合格式手冊規定,只有在“17”與“公尺”之間的空格不符合格式手冊規定;換句話說,中文語境前面與後面的空格都可以存在,只有在中文語境內部不能存在空格。關於中文語境的範疇,中文語境不包括參考文獻、模板、表格在內,而是參考文獻、模板、表格內部包含有中文語境。請問您是否同意這表述?--老陳留言) 2016年4月9日 (六) 05:55 (UTC)
首先明确,我们讨论的是源代码内的空格,还是渲染后的空格。我认为我们讨论的是渲染后的空格。凡是改动在源代码里的、不影响渲染的空格,都属于代码格式,属于“维基源代码规范”或“HTML代码规范”。对于作为模板参数等其他直接输出至页面的空格,区分是否为中文语境。height = ...中的等号之后第一个非空白字符开始为模板参数,所以“17”與“公尺”之間的空格不符合格式手冊規定。而格式手冊规定的是渲染后的页面的格式,而不是源代码格式,所以“17 公尺”前面與後面的空格属于无规范状态(加不加都不影响输出效果),所以我才说是非建设性编辑。我(+)同意參考文獻、模板、表格內部输出为HTML的文本部分(区别于标签)包含有中文語境。<span style = "color : red">17 公尺</span>输出为17 公尺,其中style前后的空格、冒号前后的空格都属于源代码中输出至HTML标签的空格,非格式手册规范的空格,而span的文本为“17 公尺”,是输出为HTML的文本。--Gqqnb留言) 2016年4月10日 (日) 20:23 (UTC)
@Gqqnb:謝謝您對於這論題的仔細分析!
  • 為了避免搞不清楚「空格」到底指的是甚麼,我們應該明確區分原始碼內的空格與渲染後的空格,暫且稱渲染後的空格為空距,因為渲染程序最後會展示出多少空白是決定於渲染軟件的輸入參數。按照您的說法,原始碼內的空格安置是屬於「維基原始碼規範」,而渲染後的空距是屬於格式手冊規範。請問我這樣表述是否符合您的說法?
  • 關於您所提到的文本問題,我不清楚「文本」指的是甚麼?所以無法明確表達我的意見。
  • 關於「17公尺」的問題,假設在原始碼內,「17」與「公尺」之間是否可以有空格屬於「維基原始碼規範」,不屬於格式手冊規範;在渲染之後「17」與「公尺」之間是否可以有空距屬於屬於格式手冊規範。請問您是否同意這說法?--老陳留言) 2016年4月13日 (三) 05:46 (UTC)
  • @老陳:,(+)同意“源代码内的空格安置是属于“维基源代码规范”,而渲染后的空距是属于格式手册规范。”。
  • 如果你在浏览器页面上右键,选择查看网页源代码(Chrome浏览器用语)/查看源(IE浏览器用语),你会看到类似<html lang="zh-CN" dir="ltr" class="client-nojs"><head><meta charset="UTF-8"/><title>维基百科:互助客栈/方针 - 维基百科,自由的百科全书</title>的内容。“文本”是HTML技术角度的词。这里的大意是“查看HTML源代码”所显示的内容,也不受格式手册规范。
  • (+)同意“假设在源代码内,“17”与“米”之间是否可以有空格属于“维基源代码规范”,不属于格式手册规范;在渲染之后“17”与“米”之间是否可以有空距属于属于格式手册规范”。这就是我表达的意见,即源代码可以有空格但渲染后无空距;或者源代码无空格但通过js或css的帮助,渲染后产生空距。--Gqqnb留言) 2016年4月13日 (三) 06:07 (UTC)
  • (-)反对,反对在数字和汉字,或英语和汉字之间插入空格。反对“13 公斤”,反对“13 kg”,也反对“km / h”,应写成“13公斤”、“13kg”和“km/h”。--7留言) 2016年4月9日 (六) 14:35 (UTC)
謝謝您的意見!希望能夠給出理由,大家集思廣益。我覺得Pityonline推薦的網路文章为什么你们就是不能加个空格呢?相當有閱讀價值,建議您有空時不妨點閱。--老陳留言) 2016年4月10日 (日) 05:47 (UTC)
7 的说法是有道理的,所谓适当留白,至少需要保留一些自有格式,不要改变原义,或造成歧义,亦非一味地为增强可读性与美观性而拙劣地添加不恰当的空格。不过我建议单纯的数字与不包括带 “/” 的中文单位间应该留白,如 13 公斤,3 份等,遇 13kg,13公斤/人,80km/h 这种,数字与右边文字不应留白,但数字左边应该留白。Pityonline留言) 2016年4月10日 (日) 06:09 (UTC)
同样反对“左边留白”,反对“体重 70公斤”,反对“距离 3000公里”,反对“风速 200公里/时”,应写成“体重70公斤”,“距离3000公里”,“风速200公里/时”。--7留言) 2016年4月10日 (日) 16:22 (UTC)
根据国际单位标准规定,数字与单位之间应有空格,因此“13 kg”是正确写法,这也是绝大多数学术书籍与期刊采用的做法。至于中文语境,尚未找到相关标准,给出此文供参考。--Wcam留言) 2016年4月10日 (日) 22:57 (UTC)
看了这个,果然留白没什么不妥的,而且 w3c 亦有此说明Pityonline留言) 2016年4月11日 (一) 00:48 (UTC)
同意Jarodalien的意见。中文语境中,传统上并无空格。我看到的专业文献中,也几乎没看到这么做的/要求的。很多时候中英/数字混排当中出现的空白并不是空格,而是排版软件自动优化的结果(所以,增加空白可以考虑,增加空格或其他类似字符反对)--百無一用是書生 () 2016年4月12日 (二) 02:25 (UTC)
如覺得數字與中文字之間要增加空白,應是採用修改CSS的方式全面調整,而不是用人工方式插入空格。所以我同意書生兄所言,別把空白跟空格兩件事搞混了!--泅水大象訐譙☎ 2016年4月12日 (二) 07:19 (UTC)
我现在倾向于添加空白,并且以在源代码中添加空格的形式添加。理由如下
  • 中英文中需要有空白:阅读了一下 Pityonline 给出的 W3C 草案,另查阅了一下相关资料,中英文之间需要有 1/4em 的空白,Word 等排版引擎也早已遵循了这一要求。
  • 不适宜使用 JS 添加:用 JS 添加理论上是可行的,但是如同我上面提到过,用JS添加需要等到 DOM Ready,在这之前页面已经呈现,不可避免地出现闪烁。
  • 尚无纯 CSS 解决方案:纯 CSS 的解决方案需要 CSS Level 4 中的 text-spacing,目前除了 IE 实现了 -ms-text-autospace 以外,其他浏览器不支持该属性,也没有其他纯 CSS 解决方法。
  • W3C 草案中提到可以使用一个西文空格做该空白的代替。
--XYZ指示物留言) 2016年4月12日 (二) 12:52 (UTC)
那么我反对这种手工加空格的做法,就像现实生活中看到这种稿件直接退稿不看一样,看到有这种来参加任何条目评选一概反对。我并不觉得这样更加美观,恰恰相反,觉得更难看。像小时一样,我也从来没有在任何论文看到过这种手动加空格的做法。英语不过是有空格分隔单词的习惯。至于那篇一开头就在下定论搞攻击,说什么“有研究显示,打字的时候不喜欢在中文和英文之间加空格的人,感情路都走得很辛苦,有七成的比例会在 34 岁的时候跟自己不爱的人结婚,而其余三成的人最后只能把遗产留给自己的猫。毕竟爱情跟书写都需要适时地留白”的狗P文章,我完全可以写个长篇大论意见完全相反的发表出来。--7留言) 2016年4月12日 (二) 13:23 (UTC)
話倒不用說的這麼死,好歹上面W大有提出規格文件證明有些是需要空格,而閣下只是印象不該加。--Liaon98 我是廢物 2016年4月12日 (二) 13:30 (UTC)
对于W3C草案问题,我觉得可以与他们讨论对草案进行修改(如果觉得加空格不合适的话)--百無一用是書生 () 2016年4月13日 (三) 02:42 (UTC)
W3C的《中文排版需求》还是working draft(草稿),还差三个版本才能成为正式的“推荐标准”,不可迷信。不过国家标准技术研究所的标准倒是可做参考。那个github上的规范,这是个论述还是什么,不清楚它的效力。--Gqqnb留言) 2016年4月13日 (三) 06:32 (UTC)
所以,根據國家標準技術研究所的規定,當表示數量時,在數字與單位之間必須有一個空格的空距。--老陳留言) 2016年4月15日 (五) 05:29 (UTC)
該單位規定的是美國、用英文撰寫時的格式,是關中文維基啥事?別混淆視聽。--泅水大象訐譙☎ 2016年4月15日 (五) 05:32 (UTC)
他山之石,可以攻錯。更嚴格地表述,根據國家標準技術研究所的規定,當表示數量時,在阿拉伯數字與英文單位之間必須有一個空格的空距。--老陳留言) 2016年4月16日 (六) 05:24 (UTC)
那仍然只定義了數字跟英文單位之間的格式,但是上面的討論是針對數字、英文與中文之間的格式介面問題,純英文的格式標準仍然毫無參考價值,不提也罷。--泅水大象訐譙☎ 2016年4月19日 (二) 04:46 (UTC)
這是第一階段,暫且只能這樣。如有任何建議,請多指教,謝謝!--老陳留言) 2016年4月22日 (五) 00:06 (UTC)
英语的数字和单词之间有空格,不过是因为单词和单词之间有空格,一向是这样写的而已,对汉语没有任何参考价值。英语写任何一句话,中间用标点分隔时也会在标点后方加上空格,这对汉语又有什么意义,如果这种也有参考价值,那完全有理由推论今后每个汉字和汉字之间也要加个空格。所以极力(-)反对。--7留言) 2016年4月22日 (五) 03:19 (UTC)
謝謝您的意見!難道當您在中文句子裏用到英文片語之時,您不會參考英文寫法?--老陳留言) 2016年4月22日 (五) 04:58 (UTC)
那又怎么样,如果是引用一句纯粹的英语,那么按照原文来写就可以,但是,汉语中即便写“15kg”而没有写“15公斤”,这个“kg”也是按汉语处理的,念出来时要么念“15千克”,要么念“15公斤”,不应该念什么“15(字母)k(字母)g”,这说明汉语中已经接受用这两个字母来代替“千克”和“公斤”,并不说明这就是在“引用”英语,而是这两个字母已经成为汉语固有的组成部分。--7留言) 2016年4月23日 (六) 16:53 (UTC)
支持7的看法。去找个小学生让他读出含有“15kg”的数学题,你会听到他念“十五千克”,而不是“十五可唉鸡”或“十五看老米特”。至少已经是汉语的组成部分,至于是固有的部分、自古以来的部分还是不可分割的部分,先不予置评。--Gqqnb留言) 2016年4月26日 (二) 00:53 (UTC)

关于追认部分Wikipedia_talk:申请成为管理人员共识为方针[编辑]

如题,该页面当中有部分已经达成的共识尚未得到确认或升级为方针,在这里发出提议,从而具体化部分要求,避免出现一些“由于申请时间距离上次申请失败时间过短”一类情况所导致的不必要的麻烦。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年3月23日 (三) 08:38 (UTC)

建議把當時討論中得出結果寫入WP:RFA#管理人員的資格對應段落內。試擬文字,若曾有申請同一權限但未通過,須待上次申請三個月後始得再次申請。--Jasonzhuocn留言) 2016年3月23日 (三) 08:45 (UTC)
附议。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年3月23日 (三) 08:46 (UTC)
附议。-和平、奮鬥、救地球!於 2016年3月23日 (三) 08:48 (UTC)
附议。--喜歡用IRCCarrotkit 2016年3月23日 (三) 08:49 (UTC)

補充,我們在Wikipedia:申请成为管理员/Billytanghh/第二次當中發現大家對冷靜期有不同的說法,但在WP空間內找不到規範文字。原來先前在Wikipedia talk:申请成为管理人员#提請修訂WP:RFA中對冷靜期的討論結果沒有寫入WP空間。現在追認冷靜期設置為三個月,寫入到WP空間去。

另外,Galaxyharrylion在RFA討論中有多一個條件,謝絕提名的情況除外。請大家展開討論,謝謝。--Jasonzhuocn留言) 2016年3月23日 (三) 08:57 (UTC)

ping一下當事人@Galaxyharrylion:-和平、奮鬥、救地球!於 2016年3月23日 (三) 09:06 (UTC)
这种情况的话,个人认为应该是该用户在没有回答任何问题的情况下拒绝提名才行,如果回答了被人灌了反对票再去拒绝提名,这规则的漏洞就太大了。回答过了删掉也不行。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年3月23日 (三) 09:09 (UTC)
@霧島聖和平奮鬥救地球CarrotkitJasonzhuocnGalaxyharrylion:這的確需要規範,不然每次被提名者還沒同意之前,就已經先行灌票動作(自薦除外)。這些種種問題的確需要探討。--Engle躍✈‎安裝文字動畫效果】 2016年3月24日 (四) 06:21 (UTC)
若直接谢绝提名,则投票实际没有开始,因此不应该受到三个月间隔限制(当然本人近期工作繁忙,短期内无暇参选)。若接受提名后中途退选,则投票实际已经开始,应受三个月间隔限制。Galaxyharrylion留言) 2016年3月25日 (五) 06:41 (UTC)
@Galaxyharrylion:下方已經提出。--Engle躍✈‎安裝文字動畫效果】 2016年3月26日 (六) 01:45 (UTC)

整理上次及上方申请成为管理人员的討論[编辑]

可以將下列的內容寫入WP:RFA#管理人員的資格

  • 當管理人員投票不通過時,緩衝期冷靜期設置為三個月,三個月內請勿再次提出申請管理人員的動作謝絕提名除外)。
  • 被提名者或自薦者签署同意意见及回答三條基本問題之时投票才开始,被提名者若超過三天未回應則自動棄權申請管理人員。

以上。--Engle躍✈‎安裝文字動畫效果】 2016年3月24日 (四) 06:33 (UTC)

  • 我觉得第二条不是一个很合适的要求。但如果这样的话,还不如改成在从被提名者签署同意意见之时投票才开始。 --达师 - 334 - 554 2016年3月24日 (四) 07:45 (UTC)
最後告示

再經過一週的討論後,未見重大異議,故在此特示最後預告:由現在起計,一週後如再沒有重大意見,將按照Special:diff/39562108進行修訂。敬請留意,謝謝!--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月8日 (五) 02:20 (UTC)

@Cdip150:有異議,原討論提出為「冷靜期」,小躍擬的文字是「緩衝期」。我認為維持原案中的冷靜期比較好。--Jasonzhuocn留言) 2016年4月12日 (二) 19:09 (UTC)
那再延長討論,而本人則建議在「管理員資格」進行修改,加入:
  • 如果以前曾經自薦或者被提名且表態接受過,但投票結果為不通過或中途退選,則自上次結束之時計起事隔至少90天。
請繼續討論,謝謝!--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月16日 (六) 17:18 (UTC)
已改成冷靜期,看還有什麼樣的問題可以添加的?--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月20日 (三) 02:05 (UTC)

小結[编辑]

大體上暫時的具體修改是:

  • 管理員資格:增加「如果以前曾經自薦或者被提名且表態接受過,但投票結果為不通過或中途退選,則自上次結束之時計起事隔至少90天。」
  • 申請權限及授權總流程:增加「檢驗被提名者或自薦冷靜期:當管理人員被提名者或自薦之投票不通過時(包含中途退選),冷靜期設置為90天,90天內請勿再次提出申請管理人員的動作(謝絕提名除外)。」

不過似乎未反映上面關於投票何時開始的意見,或者仍需更多討論。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月30日 (六) 07:28 (UTC)

用户组应该可以“删除自己的所对应的用户组”[编辑]

本内容由Stang c于2016年3月31日 (四) 06:29 (UTC)分拆。

(!)意見:如果這麼說的話,其實每個用戶組都應該設有權限「删除自己的所對應的用户组」。--就是他 ☞ Q 「祝我考試順利」「有事請留言 2016年3月20日 (日) 13:39 (UTC)

(:)回應,这是另一个问题啦。--Stang 2016年3月21日 (一) 02:10 (UTC)
@Stang:那麼這個問題是否考慮拎出來再研究?--就是他 ☞ Q 「祝考試順利」「有事請留言」 2016年3月24日 (四) 17:30 (UTC)
@StangCosine02:難道沒看到?--就是他 ☞ Q 「祝考試順利」「有事請留言」 2016年3月26日 (六) 03:34 (UTC)
真没ping到...好了,已分拆。--Stang c 2016年3月31日 (四) 06:29 (UTC)
  • (+)支持:未見其弊。-和平、奮鬥、救地球!於 2016年3月31日 (四) 07:19 (UTC)
  • 没看明白,是不是“允许用户将自己从所拥有的用户组中移除?”,是的话,去技术版说吧。——路过围观的Sakamotosan 2016年3月31日 (四) 08:32 (UTC)
    • 應該只是要徵得社群共識,技術上應無問題。-和平、奮鬥、救地球!於 2016年3月31日 (四) 09:30 (UTC)
      • 閣下說得是巡查員、回退員嗎?--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年3月31日 (四) 09:36 (UTC)
        • @小躍:您可能沒看懂我們說的。我們的意思是說,現在巡查員、回退員、IP封禁豁免者、管理員等等權限並無法自己移除自己的對應權限,例如說現在一位巡查員不能去除自己的巡查員權限。而我們想要解除這個限制,以使一位IP封禁豁免者能自我解除自己的IP封禁豁免權。-和平、奮鬥、救地球!於 2016年3月31日 (四) 09:40 (UTC)
          • (+)支持增設删除自己的所对应的用户组:IP封禁豁免者,原因:若不是IP封禁的區段,可以自行解除權限。其他為(=)中立。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年3月31日 (四) 09:47 (UTC)
    • 我不知道這是否跟基金會的政策有關?本地行政員現在也不能移除任何人(包括自己)的管理和行政權限。如果涉及基金會,即使中文社群同意,似乎也會很難過關。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年3月31日 (四) 09:51 (UTC)
      • En行政员可以移除管理员的权限。应该没关系。--Stang c 2016年3月31日 (四) 10:12 (UTC)
行政员当然可以移除管理员呢,还能任免管理员了。说什么大白话。——路过围观的Sakamotosan 2016年4月1日 (五) 00:46 (UTC)
中文維基要移除管理員是要經meta監管員才能做的(例子),行政員仍然衹能授予管理員,不能移除管理員。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月1日 (五) 05:23 (UTC)
搞错了,多谢指点。——路过围观的Sakamotosan 2016年4月1日 (五) 10:07 (UTC)
  • (~)補充:個人認為巡查員回退員IP封禁例外者巡查豁免者大量信息發送者AWB 使用者(注:根據下方兩位的說法 AWB 可能無法實現此功能)都應有權自行撤銷自己所對應的權限。對於管理員等其他人就應單獨討論了。--就是他 ☞ Q 「祝考試順利」「有事請留言2016年3月31日 (四) 13:15 (UTC)2016年4月1日 (五) 11:01 (UTC)
  • AWB的CheckUser那邊需要管理員編輯的權限......--Engle躍名字招牌快來買會動不用錢】 2016年4月1日 (五) 04:48 (UTC)
AWB使用权其实是一个Mediawiki空间页面列表,不属于系统权限范畴,这个估计除了界面编辑员、管理员级外,没人能编辑了。——路过围观的Sakamotosan 2016年4月1日 (五) 10:09 (UTC)
  • (!)意見 按照我对MediaWiki的理解,MediaWiki Core应该没有这个功能,现在的插件也没有提供这个功能。所以是要去写一个插件?(虽然不难写)--Nbdd0121留言) 2016年4月5日 (二) 16:45 (UTC)
@Nbdd0121::技术上MWConfig里的$wgGroupsRemoveFromSelf 是用来控制那些权限用户可以从自己身上移除,详见mw:Manual:$wgGroupsRemoveFromSelf,所以技术上并不需要额外开发。
从1.14版开始提供了一个参数$wgGroupsRemoveFromSelf['group'] = true;可以让设置该用户组的用户可以移除自己身上的所有用户组--南瓜留言 | 贡献) 2016年4月5日 (二) 20:09 (UTC)
谢谢指正,那就没什么问题了--Nbdd0121留言) 2016年4月5日 (二) 20:53 (UTC)

(+)支持允许IP封禁豁免者删除自己的所对应的用户组。--Stang c 2016年4月11日 (一) 02:53 (UTC)

MediaWiki的用户组除了可以提供权限以外还可以用来移除权限,虽然现在没有做这样的设置。请注意Special:UserGroupRights最上方的说明,我们可以建立一个“禁止上传”用户组,凡是加入这个用户组的都被撤销上传权限。如果简单允许用户自行移除用户组那么这种用法就无法实现了。 --达师 - 334 - 554 2016年4月11日 (一) 05:54 (UTC)

是不是需要限定那些用户组允许用户从该用户组移除出去?例如,巡查员、回退员、IP豁免、或者更多。另讨论了这么久,@qinyongr:,从哪里讨论得出需要允许自己能从用户组移除的需求?——路过围观的Sakamotosan 2016年4月11日 (一) 06:57 (UTC)
@Hat600,並不是允許所有的用戶組移除自己的用戶組的,只是巡查员,回退员,IP封禁例外者,巡查豁免者和大量信息发送者罷了(管理員等還在討論中)。--就是他 ☞ Q 「參觀 用戶頁 」「有事請 留言 」 2016年4月11日 (一) 13:53 (UTC)
@cwek,就是當時在討論大量消息發送者的時候提到了臨時發送者,然後呢臨時發送者就是要在一段時間過後自己把自己的權限取消掉,從而就有了這個討論。--就是他 ☞ Q 「參觀 用戶頁 」「有事請 留言 」 2016年4月11日 (一) 13:53 (UTC)
  • 差不多了,能不能提到phab了?-- 給我留言 「歡迎加入 #cvn-zh-scan Qinyongr 2016年4月13日 (三) 10:21 (UTC)
  • 达成什么共识允许什么群组取消自己的权限?--Stang c 2016年4月14日 (四) 09:57 (UTC)
  • 我支持巡查者、回退者、IP封禁豁免者允许自行移除对应的用户组。可以在比较小的程度上减少管理员处理自愿除权的上述用户组用户(比如工作太忙)权限调整的工作。--南瓜留言 | 贡献) 2016年4月18日 (一) 01:23 (UTC)

我覺得這段討論對於「允許IP封禁豁免者刪除自己的所對應的用戶組」應該是有共識了,而「巡查員,回退員,巡查豁免者和大量信息發送者」則也未見反對。 既然再經過超過一週的討論後,未見重大異議,可見社群應已初步達成下列二項共識:

  1. 允許IP封禁豁免者刪除自己的所對應的IP封禁豁免用戶組
  2. 允許巡查員,回退員,巡查豁免者和大量信息發送者刪除自己的所對應的巡查員,回退員,巡查豁免者和大量信息發送者用戶組

現進行公示,一週後如再沒有重大意見,將視為已達成共識,如有意見請速提出。-和平、奮鬥、救地球!留言DC14討論於 2016年4月28日 (四) 08:51 (UTC)

補充事項[编辑]

根據User:Stang在IRC上的提醒(本人表示暫時無法上來),現補充二點如果此議案通過後需要連帶做的幾點事項:
  1. 移除申请解除权限的最后一个章节,並於授予ipbe的提示语后加提示
  2. 建议在“用户权限管理”页面加入引导文字
以上。-和平、奮鬥、救地球!留言DC14討論於 2016年4月29日 (五) 12:07 (UTC)
(+)同意(就這個還編輯衝突)--Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年4月29日 (五) 12:13 (UTC)

G11是否適用個人沙盒[编辑]

如題,當今許多管理員對於用戶個人沙盒廣告皆做G11速刪處理,但上官兄指出WP:CSD在G##(##指任何數字)段落的開頭寫道:「以下標準適用於所有名字空間中的頁面,沙盒頁面除外」,故依現行方針G11似不適用用戶沙盒。亦有用戶指出對用戶沙盒進行速刪恐誤殺欲進行正常貢獻之非廣告新手。然Nbfreeh君指出User:用戶/XXXUser:用戶/沙盒是否因此會有適用性的差別、或者造成「沙盒让宣传合法化」的現象?在此ping相關用戶@ShangkuanlcAlexander MiselMys 721txPanintelizeNbfreeh:@CarrotkitTechyanJasonzhuocnChenyijia001:前來討論。-和平、奮鬥、救地球!於 2016年4月6日 (三) 00:54 (UTC)

看链接,此沙盒非彼沙盒,这里沙盒特指WP:SB或相关预设的类似功能的沙盒页面,而不包括用户子页,用户子页可以作为新建条目的沙盒,但不是所定义的沙盒。这句话只是限制对WP:SB的逻辑误删。——路过围观的Sakamotosan 2016年4月6日 (三) 01:03 (UTC)
IAR,从G字的定义来说,只要是看上去想像广告,任何人都可以都做适当的事,该回退就回退,该删除就删除,鬼管是预设沙盒还是用户子页,然后需要时背个书就是了。适当地灵活应对。——路过围观的Sakamotosan 2016年4月6日 (三) 01:07 (UTC)
“不要在沙盒進行廣告宣傳或刷编辑次数,否則可能會被封禁”。这是WP:SB里面写明的,说明沙盒并不是法外之地。但如果想要引导用户做出正确的编辑,不妨设置一个时限【比如24小时或者更短】,规定时限内没有对广告内容做出根本改善,那就删掉沙盒并且小黑屋伺候。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月6日 (三) 01:09 (UTC)
本來就很適用。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月6日 (三) 01:11 (UTC)
個人沙盒應比照其他頁面處理,不應因「沙盒」兩字而受到差別待遇。--Carrotkit歡迎參與DC14非正式投票 2016年4月6日 (三) 05:28 (UTC)
  • 或許可以擬定一個沙盒專用的WP:CSD標準,比如S1:濫用沙盒、S2:沙盒侵權、S3:沙盒明顯用於廣告用途。--宇帆(留言·) 2016年4月6日 (三) 05:34 (UTC)
我認為適用,如果不適用的話,每個用戶打着沙盒的名義來賣廣告,這還得了?還有@和平奮鬥救地球:請不要在討論一開始就ping人,討論頁指引並不鼓勵的此等做法。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月6日 (三) 06:21 (UTC)
@Cdip150:我是ping當初曾在IRC上參與相關討論的人,以及引發此事件之原提刪者,並非討論一開始。-和平、奮鬥、救地球!於 2016年4月6日 (三) 06:41 (UTC)
的確應該有一套沙盒的 CSD 標準。--就是他 ☞ Q 「參觀 我的用戶頁 」「有事請 給我留言 」 2016年4月6日 (三) 11:38 (UTC)

講實在我覺得另一個很麻煩的問題是,大家對「宣傳」的定義太嚴了。有些人根本沒有任何宣傳的動機跟意圖,只是貼的文字不太會修整,受到來源的影響,這也會被誤認為廣告宣傳。

補個實例好了,最近一個情況是使用者建立的頁面90%都是一個政府政策的「大事記表格」,也沒說政策是德政、長官英明,然後也被警告宣傳,先是提速刪後來改貼模板。我看了半天只能猜想大概大事記最後幾項有寫到跟特定企業發起合作宣傳案,稍微有那麼一點點像廣告(也在很邊緣)。

如果看起來沒有太大直接利益的文字,可否用主動修改替代速刪;另外沙盒部分雖然不可能成為化外之地,但操作上可不可以先詢問溝通再動作,不然有時候我都覺得推廣者在前線要開的是作文寫作班了。--Reke留言) 2016年4月6日 (三) 11:00 (UTC)

由于滥挂{{csd}},我已经警告过不知道多少位巡查员了。--Antigng留言) 2016年4月6日 (三) 11:12 (UTC)
吱一声。以后用鸭子 一望而知来判断。-- learningis1st留言|工作区|欢迎加入密码学专题 ฿ 2016年4月14日 (四) 19:32 (UTC)
不只是濫掛的問題,而是對文字過度挑剔,而且挑剔之後不是自己改,是對原創作者施壓。我不至於認為這會導致完全無法推廣,但會逼迫推廣者只能慢慢傾向讓新手先在維基以外的平臺寫文章,寫到安全了再貼到百科上。這其實是很糟糕的文化,會衍生包括協作意願低落、條目完成時間拉長,甚至會因此讓實體聚會中的新手對老手過度依附,各地社群鄉勇化。--Reke留言) 2016年4月6日 (三) 11:20 (UTC)
“快速刪除(简称速删)旨在加快處理顯然不合适的頁面或文件,省去存廢討論的時間。”不等于“所有顯然不合适的頁面或文件都需要快速删除。”--Antigng留言) 2016年4月6日 (三) 11:27 (UTC)

(!)意見有爭議的內容就應該送審查頁面進一步討論而不適合速刪,無論是沙盒與否。--泅水大象訐譙☎ 2016年4月6日 (三) 12:36 (UTC)

cwek已经说得非常明白,沙盒指的是WP:SB这个单一页面。Bluedeck 2016年4月7日 (四) 03:29 (UTC)
除非页面存在的问题是一眼已发现明显符合快速删除方针,否则快速删除应可免则免。因为判断快速删除的参与者通常不出挂模板者及管理员两人,容易出现主观判断,所以页面如不是明显破坏,应转交存废讨论,由更多用户参与决定其存废。最近有不少新条目,虽然只有第一方来源,或有宣传情况,但这些来源有缺的条目,本应循关注度处理,给编者有时间增补来源,其他用户也可协助整理条目内容,但近期有不少巡查者却直接以 G11请求快速删除,连关注度程序都跳过,而没有把删除页面作为最后手段。--Thomas.Lu留言) 2016年4月10日 (日) 16:28 (UTC)
我個人更傾向於支持G11適用於個人沙盒,不然可能會有很多人利用這個空子,利用維基百科來作廣告宣傳。像吳語維基百科那裡就有很多人利用用戶頁來搞廣告宣傳,弄得是一團糟。我怕中文維基也會成為那樣。--el caballero de los Leones (Ajouter un message)CKJV 2016年4月13日 (三) 11:59 (UTC)
建议G11适用于沙盒,自己向来也是这样做(可能以后会更注意AGF)。但像 Topic:T1wjv9wrg7ain1ci 这样的例子我也觉得无法避免。(&)建議 在Editnote里说明沙盒里不建议放什么什么。 -- learningis1st留言|工作区|欢迎加入密码学专题 ฿ 2016年4月14日 (四) 19:09 (UTC)

根據大家在上面的討論,我有以下提案:

  1. 既然個人沙盒非法外之地,將「以下标准适用于所有名字空间中的页面,沙盒页面除外。」改為「以下标准适用于所有名字空间中的页面,公用沙盒页面除外。」
  2. 鑑於避免誤會,且删除页面为最后手段,或許可在G11之說明加上「即便該頁面具有宣傳情況,除非您可以非常確定該頁面建立僅為廣告宣傳而建,否則應以關注度提報或提刪替代」之類的提醒。
  3. 對於個人沙盒頁面應採用比主條目頁面更寬鬆的規範,畢竟就算在個人沙盒裡面打廣告,其效果應該也不大,原作者也可能只是先雜亂堆積一些資料在沙盒而非為了進行廣告。
以上。-和平、奮鬥、救地球!於 2016年4月18日 (一) 01:53 (UTC)

(+)支持Peace的观点。--Techyan留言) 2016年4月23日 (六) 12:24 (UTC)

应该删掉“沙盒页面除外”。本来速删就是针对新建页面,非新建页面出现符合CSD问题优先回退,没必要想着沙盒如何如何。 --达师 - 334 - 554 2016年4月24日 (日) 12:48 (UTC)

关于维基百科的言论自由与恶意攻击之间的界限,伴随对user:Galaxyharrylion近期的行为的思考[编辑]

请Bluedeck账户当前的操作者就其对本人的污蔑和骚扰行为进行道歉[编辑]

提議優特評選排隊制[编辑]

最近的優特評選同時提太多了,其中6+提的最多,優、特合起來就提了十多個,把參與分薄了,討論遠不如幾年前的深入。很多含有錯誤的條目,往往還沒來的及仔細看完,又一批提上來了。無論是新提名或是撤銷都沒有經過充分的審視和討論。

我提議引入早期「質量提升計畫」選條時所用的投票排隊制,設置同時評選的上限,超過這個數就排隊。--Jasonzhuocn留言) 2016年4月11日 (一) 01:27 (UTC)

(+)同意,不知道其他人有沒有什麼想法?-和平、奮鬥、救地球!於 2016年4月16日 (六) 06:55 (UTC)
排队排多少个?Bluedeck 2016年4月16日 (六) 07:33 (UTC)
我認為條目評選沒有經過充分的審視和討論就草草了事的現象,就算條目再少,也不會治本。因為並不是制度出問題,而是群眾的心理質素出問題。除非改為評審制和廢除評選時限。PS. 樓上這個很容易被「遊樂場主義者」亂答啊,他們可以說「五個」,然後又不給出紮實的理據,就看你怎麼奈何。--春卷柯南-發前人所未知 ( ) 2016年4月16日 (六) 09:31 (UTC)
额,虽然这个问题问的不好,可是如果要排队的话,数量这个问题就是不能避免的啊。Bluedeck 2016年4月17日 (日) 03:33 (UTC)
(!)意見,最好能夠對同時評選的同類條目數量加以限制,這樣可以促使優特評選的多元化。--老陳留言) 2016年4月17日 (日) 05:06 (UTC)
(?)疑問:如果如此限制,但其他類別條目提報數量卻甚少,似乎仍不足以達成多元化?-和平、奮鬥、救地球!於 2016年4月18日 (一) 02:38 (UTC)
其实老陈担心的问题应该是连续数天或者几天之内多次被同一类别的优特存档刷屏吧。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月18日 (一) 02:43 (UTC)
我會覺得有關"同時評選的同類條目數量加以限制",這一部份另案討論會不會比較好?--Wolfch (留言) 2016年4月18日 (一) 03:27 (UTC)
也可以。-和平、奮鬥、救地球!於 2016年4月18日 (一) 03:31 (UTC)
(!)意見:同意老陈的意见。 AndyHe829留言) 2016年4月17日 (日) 05:18 (UTC)
(!)意見:你们这样做,不怕有人又要抱怨是针对他的么?——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★贡献 2016年4月17日 (日) 05:28 (UTC)
我是覺得不會,因為這樣可以讓他主編的條目獲得更多檢視的機會,減少錯誤並改善其品質。-和平、奮鬥、救地球!於 2016年4月18日 (一) 01:27 (UTC)
(!)意見:同意老陈的意见+2--4Li 2016年4月18日 (一) 02:34 (UTC)
(+)支持,类似于授奖提名投票,搞一个这样的制度没有啥问题。至于类别和数量,个人认为那是下一阶段的讨论内容。--门可罗雀的霧島診所欢迎光临神社的羽毛飘啊飘 2016年4月18日 (一) 01:31 (UTC)
(+)支持,同意在優特評選導入同時評選的上限--Wolfch (留言) 2016年4月18日 (一) 01:40 (UTC)
優良條目每天展出一個,所以可以設定若預計展示的優良條目已經排到N天(M週)後,就一天只放行一個評選。至於同類限制我是不太支持,維基百科本來就鼓勵高品質條目產出,不該限制類別--Liaon98 我是廢物 2016年4月19日 (二) 16:40 (UTC)
DYK也应该吧,不都是条目评选么,还经常因为事后发现“含有錯誤”吵呢。另外,“多元化”恐怕需要多一堆编辑来写才能解决,盯着我怕没啥用,比如说我如果某个月写了30个气象类,但别的人没有29个人(甚至9个人)来写怎么办呢。时限到了,没人投票就不会通过,现在FAC还有几个?GAN又有多少个?关键完全不过是我有没有在写,又都是在写什么嘛。--7留言) 2016年4月19日 (二) 16:51 (UTC)
有關DYK評選是否要排隊,以及優特評選是否要依類別作其他處理,非此次主題,我建議另案討論--Wolfch (留言) 2016年4月20日 (三) 03:13 (UTC)
那又不明确给个数量,怎么讨论下去呢?同时只能有一个?两个?三个?四个?五个?六个?七个?重审受不受限制?重审数是否限制新提名评选数?优良条目和特色条目限制数量是否相同?按什么标准来计算数量?优良如果一天一个最多只可能有七个,但特色要是一天一个就会有14个了,还是“太多”怎么办……--7留言) 2016年4月20日 (三) 06:01 (UTC)
如果以我上面的說法(上首頁的日子來限制),那麼需要排隊時就是一天放一個(因為首頁一天展示一個),不需要排隊時一天幾個都可(直到塞到需要排隊)。如果上首頁已排到30天後,以GAN七天來說,那麼在23天後以前哪天通過,上首頁都是排在31天後,不是一樣嗎。所以我認為可以用上首頁的時間來排,例如限制通過後要在N天內展示到首頁,若無法N天內展示,就先排隊排到能在通過N天內上首頁的日子開始評。而現在重選不影響上首頁,可能得另外想辦法。以上是一點想法--Liaon98 我是廢物 2016年4月21日 (四) 15:54 (UTC)
(!)意見,是否應該專門設立一個特優條目小組,邀請熱心於維護特優條目與對特優條目做出重大貢獻的維基人士聚集在一起,專門研討相關問題,說不定能夠找到可行辦法?--老陳留言) 2016年4月23日 (六) 18:41 (UTC)

@Wolfch霧島聖老陳和平奮鬥救地球:能否說說心裡面的數字?--Jasonzhuocn留言) 2016年4月30日 (六) 05:16 (UTC)

方針指引、格式手冊列表的模板[编辑]

方針指引模板[编辑]

  • T:方針列表T:指引列表因為缺乏更新而少了一些方針指引,我將其補上,卻被IP使用者回退,表示加進來會變得太長,挑幾個放就好,細問該挑何者,他又說大家覺得重要的放入自然就行,但我覺得各方針指引都一樣重要,都該放入,他又獨獨反對我的意見(可以接受其他人放入,卻不准我放入真神邏輯也)。來這邊問問大家意見,是否更新至全部放入+排版的版本(見該模板討論頁)。--Liaon98 我是廢物 2016年4月11日 (一) 02:25 (UTC)
  • 這個挑選太主觀的,那還不如只列五大支柱算了(另外我覺得現在這兩個模板的數量並不算多,比起英文維基的話)--Liaon98 我是廢物 2016年4月11日 (一) 03:29 (UTC)
  • 另一個方法是內容方針一個模板,合作方針一個模板,使用者方針一個模板,東西變大要拆很自然,指引也是有分拆的模板(像是關注度、版權、格式這類指引都是個別模板)--Liaon98 我是廢物 2016年4月11日 (一) 03:43 (UTC)

最好底部导航。 --达师 - 334 - 554 2016年4月13日 (三) 07:50 (UTC)

@hat600:底部導航另有T:Rules模板,現在是在討論右側模板該怎麼寫--Liaon98 我是廢物 2016年4月13日 (三) 07:54 (UTC)
有底部导航的话不建议再加右侧导航。本来右侧导航就是个很麻烦的东西。 --达师 - 334 - 554 2016年4月13日 (三) 07:55 (UTC)
@hat600:如果不用這兩個模板,是要刪除?--Liaon98 我是廢物 2016年4月18日 (一) 13:53 (UTC)
斷然刪除我也不贊成,其實我覺得無必要說中不中立,方針指引本來就是各有不同的重要程度。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月18日 (一) 13:56 (UTC)
我是主张删除的。 --达师 - 334 - 554 2016年4月20日 (三) 04:44 (UTC)
那麼先不刪除,之後就暫時把各方針指引頁的頂測導航移掉好了--Liaon98 我是廢物 2016年4月29日 (五) 11:56 (UTC)
如果不刪除,但卻把它移除掉,那不刪除的意義在哪?我反對刪除,自然也反對移掉。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月30日 (六) 07:20 (UTC)
移除慢慢弄出個好版本再放回,跟草稿差不多概念,刪除就完全沒有了。但我還是不明白為何需要做到兩份幾乎一樣意義的模板,若真的要用少量連結,我上方也提了將各分類各建一個頂側模板(如關注度模板),但閣下未給意見--Liaon98 我是廢物 2016年4月30日 (六) 18:47 (UTC)

格式手冊模板[编辑]

  • 其二是T:格式手冊T:Style。我的認知是,受眾人討論獲共識升格為格式指引的頁面,才能算是格式手冊,才該放在這兩個模板內,畢竟將草案跟指引放在一起會誤導人以為這些尚非指引的頁面也是指引,所以我先前將這兩個模板中,非指引的改成灰色,但隨後被L管理員回退,因此我直接將非指引的移除,但又遭到O大回退,他認為「被看到也無妨」。我的意見是指引跟非指引要分清楚,不然任何人撰寫一篇未獲共識的頁面,就放上這個模板,豈非大亂了?英文維基那邊就分的很清楚,有另外設計一個格式、內容相關論述的列表模板,而格式手冊模板就專門放格式指引。各位覺得是否應該移除這兩個模板內的非指引?--Liaon98 我是廢物 2016年4月11日 (一) 02:25 (UTC)
  • 原本有用顏色分,但被回退;紅字的是英文維基的格式指引,以前該模板就一直放有(只是用註解隱藏)。我個人是傾向不是格式指引就不要列,因為任何人都能寫草案,也不一定被檢查,所以未獲共識的非指引列上去我覺得不太好。--Liaon98 我是廢物 2016年4月11日 (一) 03:29 (UTC)
  • 第一,只保留底端。第二,同意以某种方式标记未通过的指引。 --达师 - 334 - 554 2016年4月20日 (三) 11:05 (UTC)
  • @Liangent:大大回退了用顏色區別,那麼是否有比較好的方法呢?用灰色表示非正式的作法,在中文維基上的地鐵路線大多這麼做,我當初是以相同想法才這樣標的。另外有看過用斜體,但是斜體的漢字很醜。還是說像{{关注度标准导航}}這般?但是關注度的頁面數量較少,若格式手冊這樣用感覺下面會塞一卡車...--Liaon98 我是廢物 2016年4月20日 (三) 11:42 (UTC)
    • 这样?或者就拆成两个模板?Liangent留言 2016年4月22日 (五) 02:35 (UTC)
人人都可以编写论述,都加到模板里难道不会过长吗?不要费尽心思去区分哪些论述可以加,不要给什么英文版来的论述特权。简单起见,只应当包括方针。--Gqqnb留言) 2016年4月26日 (二) 01:04 (UTC)
  • 目前來看的共識是,論述必須區別,區別方式看是標記還是分拆模板。既然我問分拆沒什麼有意見,那等此次討論存檔後,我便分拆。--Liaon98 我是廢物 2016年4月29日 (五) 11:56 (UTC)
  • 不要拆開兩個模板,那樣分類又要重複列出,相當累贅。用之前的斜體來區分就夠了,醜不一定是不好,把字弄難看一點會讓人有所避諱而不會亂用。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月30日 (六) 07:20 (UTC)
  • 拆兩個、分類重複列出等,我覺得不算多大的問題。英文維基那也是論述跟方針指引各一個模板的(en:Template:Wikipedia policies and guidelinesen:Template:Wikipedia essays)。中文維基現在有個很大的問題就是總是把論述頁當方針指引來引用,連老手也常這麼做,造成新人誤會,明確區分我認為是很好的做法。而且這種論述可以跟方針指引擺在一起的先例一開(不管過去怎樣隨便),其他人便可接著在規則相關導航模板也跟著加入論述,中文維基有上百個論述,若是真的把內容相關論述放在內容方針指引旁,提刪論述放在刪除方針旁等,那可是一場大亂--Liaon98 我是廢物 2016年4月30日 (六) 18:42 (UTC)
我觉得用灰色标记挺好的啊……如果觉得论述门槛太低,可以仅列出“指引草案”或者“对应页面在英文为指引”的页面,这些一般比较靠谱。—Chiefwei - - ) 2016年5月1日 (日) 02:15 (UTC)
唔,可是像Wikipedia:格式手冊/電視en:Wikipedia:Manual_of_Style/Television,這內容差異是非常大的...話說草案的定義英文維基那邊好像是正放在互助客棧討論的才叫草案,但中文維基似乎只要寫好頁面就掛著草案,然後掛到天荒地老也沒拿來客棧討論...--Liaon98 我是廢物 2016年5月1日 (日) 09:43 (UTC)
建议把模板定位为内容指南,里面放内容相对充实的格式指导页面,正式页面加粗/上色显示。中文维基目前条目架构这种大方向都很成问题,这点上能帮助条目的论述都可收录。如果用条目评级来说,就是能把条目指导到丙级的页面。只收录正式页面的话,中文版格式手册又没几个,不如和方针列表合到一起。--風中的刀劍留言) 2016年5月1日 (日) 10:42 (UTC)

提交Wikipedia:用户查核请求时需通知用户[编辑]

如题。建议修改Wikipedia:用户查核请求,向其添加“请您在提交用户查核后,务必使用{{subst:Socksuspectnotice}}模板通知被怀疑滥用傀儡的用户。请于主账户讨论页放置上述模板。”字段。

有些时候被提交的用户对此事并不知情,例如一些新手(如:Lindenk)。通知会让用户知晓此事,并可能可以使用户了解傀儡方针。另外,我个人认为通知当事人是一种基本的维基礼仪。恳请达成共识,谢谢。--Stang c 2016年4月12日 (二) 09:50 (UTC)
  • (+)支持,應該強制修要求通知用戶。並把這個弄到 Twinkle 的默認設置裡。--就是他 ☞ Q 「參觀 用戶頁 」「有事請 留言 」 2016年4月12日 (二) 10:56 (UTC)
    • en区里有ARV,在用户讨论页就可以提报WP:VIPWP:UAAWP:RFCU等等操作(相关页面已本地化)。可以考虑引进。--Stang c 2016年4月12日 (二) 11:01 (UTC)
  • (+)支持,用戶查核涉及用戶的隱私信息,應當進行通知。--Innocentius留言) 2016年4月12日 (二) 23:01 (UTC)
  • 应当通知所有被提报的用户。 --达师 - 334 - 554 2016年4月13日 (三) 07:38 (UTC)
(+)支持,應強制知會用戶,並給予空間辯解。--James970028 · 歡慶編輯數破萬 2016年4月14日 (四) 15:01 (UTC)
  • (+)支持,应该通知--Gqqnb留言) 2016年4月15日 (五) 02:42 (UTC)
  • (!)意見,若被查核者是持续出没的惯犯呢?--Lanwi1(留言) 2016年4月15日 (五) 02:59 (UTC)
    • 你通知了他,他又不能把相关证据抹掉。--Antigng留言) 2016年4月15日 (五) 03:07 (UTC)
  • (!)意見,對於慣犯,沒有必要浪費時間。--老陳留言) 2016年4月17日 (日) 05:09 (UTC)
    • WP:AGF对任何人都适用。有时间报VIP就有时间通知相关用户。--Antigng留言) 2016年4月17日 (日) 05:11 (UTC)
  • (+)支持:既然要保持礼仪,多一个程序也不多。——蘇州宇文宙武的主頁 ♨留言 ☎交友 ★贡献 2016年4月17日 (日) 05:24 (UTC)
  • (+)支持:除了上面的意見之外,還加上WP:AGF。其實這並不會浪費太多時間,又可以因為給予辯解機會而減少誤判之情形。個人認為誤會了一個善良用戶比放走了一隻慣犯還要來的嚴重,況且這並不太會放走慣犯。-和平、奮鬥、救地球!於 2016年4月18日 (一) 01:24 (UTC)
  • (+)支持,不过用户被CU已经有页面右上角的红色警铃提示了。--4Li 2016年4月18日 (一) 02:31 (UTC)
  • (+)支持,被查核的用戶的確要提醒,並且還要附上固定連結的版本。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月18日 (一) 04:44 (UTC)

小结:看来社群已经达成共识,需要通知被查核用户,但就通知“所有被提报的用户”还是其他存在异议。下面讨论此问题。--Stang c 2016年4月19日 (二) 10:12 (UTC)

通知哪些用户[编辑]

下面讨论此问题。--Stang c 2016年4月19日 (二) 10:12 (UTC)

  • 所有被提报的用户。我们不应假定某用户是主账号而其他是分身。 --达师 - 334 - 554 2016年4月20日 (三) 04:46 (UTC)
  • (+)支持:所有被踢爆提報用戶,如果結果是無關聯,那麼根據要提醒所有用戶。-- 給我留言 「歡迎加入 #cvn-zh-scan Qinyongr 2016年4月20日 (三) 11:30 (UTC)
    • 工作量有点大啊?可否写个脚本?--Stang c 2016年4月20日 (三) 14:07 (UTC)

提议修改WP:RFDA[编辑]

WP:RFDA

行政员与管理员解任条件是相同的,但除非提起解任者指明不取消其管理员权限,否则被解任的行政员的两项权限将同时被解除。

当初制定此条款时本地CU和OS均未启用,但在CU和OS启用时均未对条款进行调整。近日出现罢免OS的案件,故提议将本款扩大为全部需经过WP:RFA流程的权限,具体文字如下:

  • 行政员用户查核员监督员与管理员解任条件是相同的。但除非提请解任者指明只取消其某一项或几项权限,被解任用户的行政员、用户查核员和监督员权限将同时被移除。由于行政员、用户查核员和监督员均须由管理员兼任,因此如若提请解除管理员权限,这些权限将不能保留。

本修正案通过后,将不影响通过时已开始的解任案。 --达师 - 334 - 554 2016年4月17日 (日) 08:52 (UTC)

  • +1。--Antigng留言) 2016年4月18日 (一) 00:31 (UTC)
  • 那么“通过时已开始的解任案”该如何处理?--4Li 2016年4月18日 (一) 02:29 (UTC)
    • 应查找其他方针,或由行政员定夺,或另外讨论。可参照本次修改,但不应简单按修改后的方针执行。 --达师 - 334 - 554 2016年4月20日 (三) 04:42 (UTC)
  • 通常行政员用户查核员监督员是管理員的進階管理模式,本來就在同一個屋簷下。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月18日 (一) 04:48 (UTC)
  • (+)支持,而「通过时已开始的解任案」則衹移除指定的權限,如沒有指明是管理員權限,則予以保留。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月18日 (一) 14:05 (UTC)

无人回应已逾一周,也无人反对,视为达成共识。上述修正案已加入WP:RFDA。 --达师 - 334 - 554 2016年4月26日 (二) 07:16 (UTC)

藝人的錄影紀錄 可否刪除?[编辑]

  • 過去的討論2015.02-錄影紀錄。目前處理藝人的錄影紀錄處理 僅針對沒有來源的流水帳! 如果刪掉當下有熱情粉絲使用還原,我也會到對方的對話頁留下我的留言跟看法,除此之外,有沒有建議啥適合的處理方式呢? 常常碰到熱情的粉絲不願刪除資料 造成編輯戰往往返返! Zenk0113留言) 2016年4月18日 (一) 06:45 (UTC)
  • 不是! 單純上節目或是上電台的錄影紀錄!(目前被我清理過的大概都是沒來源或是流水帳的)!! 以陳研希的條目為例,我是不會去動它的! F(x)影視作品列表這個條目為例,我就會刪掉綜藝節目的嘉賓出演及電台的嘉賓出演! (很多韓國藝人的條目喜歡用嘉賓演出這個詞,大概就是綜藝節目的來賓的意思)Zenk0113留言) 2016年4月19日 (二) 11:18 (UTC)
  • 明白了。就是作为嘉宾出席过的节目的列表。这部分内容即使有来源,也属于细碎的数据。没有来源的部分应可直接删去。Bluedeck 2016年4月20日 (三) 03:05 (UTC)
@Zenk0113:閣下跟幾位愛好者在使用者talk頁吵架還不如請他們來此發表意見吧--Liaon98 我是廢物 2016年4月29日 (五) 11:54 (UTC)
都有提醒了! 包括從來不願意給還原理由的用戶們! 第一次還原那些細項無來源內容的時後都會告知! 同樣的事,去年也有做過一次!不過成效就.....大部分熱情的粉絲不會回應你 只會不斷退回!好一點就來跟你說有多辛苦了!然後講一些沒有邏輯的話! 很少碰到有人願意跟你討論方針的熱情者! Zenk0113留言) 2016年4月30日 (六) 05:30 (UTC)

提议修改WP:RFDA[编辑]

WP:RFDA:

 若总有效票数达25票或以上,且支持解任票数超过50%者,则投票通过。

提議修改為:

 若總有效票數達25票或以上,且反對解任票數不超過50%者,則投票通過。

提議的根本原因如下:

管理員能夠擁有其權限的根本原因是社群支持的共識,就算是解任投票也不應例外。

反對解任票數不超過50%,代表其已經失去了社群50%以上的信任度,故該解任投票理應為通過。(請各位不妨思考一個問題:若一次解任投票的結果為29/33/10,這個人再進行一次管理員授權投票,是否有可能會通過?是否應當授予管理權限?)

本提案主要目的在於加強社群對管理層級的控制,及減小開啟和通過不信任投票的門檻;加強管理員的危機意識,優化管理層級的做事效率和辦事態度;增加投下中立票的個人的責任意識。

請各位檢討。

注:由於本提案設計管理以上權限維基人的根本利益,故該層級應當避嫌。避嫌仅适用于表示支持或反对。

注2:本提案不適用于當前正在進行的解任投票。

祝安。 --Innocentius留言) 2016年4月20日 (三) 04:50 (UTC)

反对反向选择,中立票更多是出于对被罢免人员的中立表度(不觉得太好、但不至于太差的意见),只有在正反票相近时才会用于合并统计。所以对于这类严肃的人事任免,应取正向选择而不是非向选择,以免错误包含中立人。——路过围观的Sakamotosan 2016年4月20日 (三) 05:03 (UTC)
中文维基百科真的有中立票算数的投票吗…… --达师 - 334 - 554 2016年4月20日 (三) 05:05 (UTC)
好像以前见过。(?)——路过围观的Sakamotosan 2016年4月20日 (三) 06:08 (UTC)
既然討論發起者認為管理員以上權限用戶應當避嫌,我就提出幾個疑問就好,以協助釐清整個規則,不表示支持或反對意見:
  1. 原條文與新條文之「總有效票數」是否有將中立票計入?
  2. 若上面屬實,則:
    1. 原條文是否將「中立票」與「反對解任票」置於同一地位?有何利弊?
    2. 新條文是否將「中立票」與「支持解任票」置於同一地位?有何利弊?
以上。-和平、奮鬥、救地球!留言DC14討論於 2016年4月20日 (三) 09:01 (UTC)
  • 中立票应当计入总有效票数,但只在支持票及反对票相同票数时,中立票附上的理据才会被考虑。
  • 中立票的投票人是须要符合人事任免投票资格,其地位不同于只可在意见区发表个人观点的IP及用户,因此其投票仍属参与该等人事任免投票的有效票。
  • 然而,中立票不应被自动视为支持或反对某一投票议案,因为中立票附上的意见是倾向支持或反对皆有之,意见并不一致,中立票往往是认同某一观点,但认为尚未须要执行该决议的程度。--Thomas.Lu留言) 2016年4月20日 (三) 10:35 (UTC)
    • WP:RFDA,人事任免投票资格并不适用于中立票。 --达师 - 334 - 554 2016年4月20日 (三) 10:38 (UTC)
Wikipedia:申请罢免管理员说“可以投支持票(同意罢免)或反对票(反对罢免)”,没有提及中立票。如有人投中立票,理应不计入有效票数内,不过我不反对在该方针内加入更明确的说明。--Mewaqua 2009年6月28日 (日) 11:30 (UTC)

--达师 - 334 - 554 2016年4月20日 (三) 10:50 (UTC)

感謝回應!下方匯總一下在下的幾個回應:

  1. 中立票理應計入總有效票數,以加強中立票的作用和投下中立票的個人的責任意識。
  2. 雖然未出現達師所述“支持票比反对票多,但计算中立票时支持不足50%”,但是的確出現過“反對票比支持票多,但計算中立票时反對不足50%”的情況。在這種情況下中立票應當能發揮自己的作用。
  3. 在下的思考中,管理員離任投票並非“解任”而是“可否繼續擔任”的投票。由此:支持票=反對继续担任,反對票=同意繼續擔任,中立票=不支持繼續擔任。在下肚子裏的墨水不夠,沒法總結出兩種結算方式的利弊,望各位指教。--Innocentius留言) 2016年4月20日 (三) 14:14 (UTC)
  4. 亦可以添加如下:
    1. 支持 > 反對 + 中立:解任
    2. 反對 > 支持 + 中立:保留
    3. 支持 < 反對 + 中立 且 反對 <支持 + 中立:無共識,留權查看2月後再度投票,且二次投票表决不设立中立票。
類似的。--Innocentius留言) 2016年4月20日 (三) 14:21 (UTC)

此办法如果执行,等同于管理员群体自埋炸弹,不知道为何上面聊得挺高兴的管理员们为何这么简单的道理都看不出。--Herfjotur留言) 2016年4月20日 (三) 16:39 (UTC)

责任意识?这是强迫站队吧?我就是不反对不支持某人路过围观刷刷存在感,你咬呀。我认为根本没必要强调中立所谓的责任意识,该反对该支持的早就直接投下去,中立摇摆的就随他呗。勉强没幸福。——路过围观的Sakamotosan 2016年4月21日 (四) 04:18 (UTC)
真得不想看到管理員們染上旁邊的墨汁。--►不讓你們窩裡反的Ricknator11♥)◁ 2016年4月20日 (三) 17:45 (UTC)

感謝二位@Herfjotur:@Ricknator:的回應。

首先在下完全同意Herfjotur對本議案的描述,即"群體自埋炸彈"。這點在下也在一開始時有說明,即本议案的目的是加強社群對管理團隊的控制,而想必上方參與討論的各位管理員也一定已經意識到了。且在下也意識到這個議案觸及管理層次的根本利益,是以要求避嫌。(避嫌僅限於投票反對和支持,這點在下已修正)

誠然,這個議案會大幅度減小管理員解任的阻力,但是在下覺得當下維基百科正是需要這種改變。

在此在下引用維基百科:管理員:

 管理员没有任何高于其他用户的特权,唯能实现社区讨论所得的共识。

然而各位不妨思考,現在的維基百科真的是這樣嗎。

打比方說:Wikipedia_talk:管理員的離任中不下數次討論過不活躍管理員的問題,結果依舊不了了之。6個月一次編輯,這樣的管理員真的能夠促進社群討論的共識,甚至是維持維基百科基本的運行嗎。

在下不願點名指出,但是在近幾周的互助客棧討論中,數位管理員無法做到冷靜的討論和善意對待用戶,作為社群的代表人,這樣的情況真的不需要改善嗎。

在此還需要說明本議題的用意。

管理員唯能實現社區討論所得的共識。那麼什麼樣的管理員能夠實現並促成共識?

在下認為,不是的“不支持率少於50%”的管理員,而是“支持率多於50%”的管理員。

這個議案的目的,便是敲響“支持率不達50%”的管理員的警鐘,督促其務實進行維基百科的工作,善意對待其他編者,同時不要一意孤行違背社群共識。

誠然,這個議案便如同一個炸彈,會造成大量的不確定因素。

但是在面臨一堵柏林牆的時候,您是會試圖繞過去?還是選擇一點一點鑿開這牆壁?

在下會選擇直接用當量足夠的炸藥炸開,如同Herfjotur所比喻的。

在下對長文深表歉意,祝各位編安。--Innocentius留言) 2016年4月20日 (三) 19:49 (UTC)


你所谓的“Wikipedia_talk:管理員的離任中不下數次討論過不活躍管理員的問題,結果依舊不了了之”与实际情况不符。实际情况是大量的用户反对缩短这一期限,包括我在内。我还认为应当设立resysop机制。--Antigng留言) 2016年4月21日 (四) 04:28 (UTC)
據討論存檔,最近一次的有組織投票在7年以前且無共識,之後的討論均沒有深入問題和達成共識。在下想這應該符合不了了之的概念吧。--Innocentius留言) 2016年4月21日 (四) 04:32 (UTC)
Wikipedia:投票/缩减管理员不活动期限讨论得清清楚楚。--Antigng留言) 2016年4月21日 (四) 04:43 (UTC)
反对的多为管理员。另外,中文维基本来是没有解任机制,当时反对设立解任投票的管理员也不是少数。--Thomas.Lu留言) 2016年4月21日 (四) 05:31 (UTC)

提案的修正[编辑]

進行如下修正:

 若總有效票數(有效支持票,反對票,中立票)達25票以上,按照以下首條符合情況的細則進行處理:
 1.支持 > 反對 + 中立 : 支持解任超過半數,明顯不再適合擔任管理員一職。結束投票後立刻除權,並進入至少6個月的申請冷靜期。
 2.支持 < 反對 + 中立 但 支持 > 反對 :不信任率達半數,基本達成解任共識。結束投票後應除權,並進入6個月的申請冷靜期。
 3.反對 < 支持 且 反對 + 中立 > 支持:無基本共識。投票結束後進行公示,涉及的管理員留位查看,並於3個月後進行二次投票,投票應參照Wikipedia:申请成为管理人员的標準。
 4.反對 > 支持 + 中立 :信任率達半數以上,應酌情進行警告,不進行除權。

希望各位發表建議。

  • (-)反对,这一建议视投票如儿戏。--Antigng留言) 2016年4月21日 (四) 04:29 (UTC)
    • 請您確切指出哪裡“視投票如兒戲”,在下不會接受沒有理由的誹謗。另,閣下屬於管理員團隊,應懂得避嫌不進行支持反對投票。--Innocentius留言) 2016年4月21日 (四) 04:35 (UTC)
      • “涉及的管理員留位查看,並於3個月後進行二次投票”,投票想开就开啊?本身维基百科依赖WP:共识运作,WP:投票不能代替讨论,你倒好,反而增加投票项目和时间,与方针的初衷是违背的。--Antigng留言) 2016年4月21日 (四) 04:43 (UTC)
  • (-)反对,中文維基百科的「中立票」不應被解讀為有「支持」或「反對」的效果。--Mewaqua留言) 2016年4月21日 (四) 04:45 (UTC)
  • (-)反对,明显偏向罢免管理员。--4Li 2016年4月21日 (四) 05:27 (UTC)
  • 中立票可视为出席该项投票,但不应划入支持或反对有关投票议案。--Thomas.Lu留言) 2016年4月21日 (四) 05:37 (UTC)
  • (-)反对, 明顯不公。這樣會隨時出現問題,而且真的對管理員不公平。我認為應有以下反建議:
 若總有效票數(有效支持票,反對票,中立票)達25票以上,按照以下首條符合情況的細則進行處理:
 1. 支持 > 反對 + 中立 : 支持解任超過半數,明顯不再適合擔任管理員一職。結束投票後立刻除權,並進入至少6個月的申請冷靜期。如果
 2.支持 < 反對 + 中立 但 支持 > 反對 :無基本共識。投票結束後進行公示,涉及的管理員留位查看,並於1個月後進行二次投票,投票應參照Wikipedia:管理員解任投票的標準。
 3.反對 < 支持 且 反對 + 中立 > 支持:無基本共識。投票結束後進行公示,涉及的管理員留位查看,並於3個月後進行二次投票,投票應參照Wikipedia:管理員解任投票的標準。
 4.反對 > 支持 + 中立 :信任率達半數以上,不應警告,不應除權。
 注:方案2和3將會繞過發起解任投票的時限規定而進行解任投票的程序

|1233 | 有問題? 2016年4月21日 (四) 08:45 (UTC)

  • (-)反对,应当和WP:RFA及中文维基百科其他常规投票相同处理,中立票视为弃权,不计入总数,也不参与数量比较。 --达师 - 334 - 554 2016年4月21日 (四) 13:24 (UTC)
  • (!)意見,好像楼主找过我,我提个意见,你的新方案太复杂,我第一眼就不想看了。或者这么说,其实你修改方案的初衷在哪里?现有方案有什么问题?--Herfjotur留言) 2016年4月21日 (四) 14:30 (UTC)
  • 以前就回答过这个问题,由于投中立票者必须将原有的票删除,才能再投支持或反对,我觉得这很显然就已经承认中立票也是有效票。--7留言) 2016年4月21日 (四) 15:41 (UTC)
  • 在下希望澄清一下。這不是投票。這個議題本身還太不成熟,達不到得到共識的條件。在下希望各位能提供建設性的意見和建議。祝安。--Innocentius留言) 2016年4月21日 (四) 19:09 (UTC)
@Lnnocentius:,中立票只是刷存在感而已,如果硬生生算成有效的支持解任票数,像special:diff/39868621一众不反对不支持的人最后被算成解任友军的话,真想像不到他们N脸懵逼的样子。就此作罢吧——路过围观的Sakamotosan 2016年4月23日 (六) 01:33 (UTC)
另,从AddisWang、天天、范的解任讨论突然之间引出各种提高解任火力的方案修改,突然嗅到一股阴谋论的味道……——路过围观的Sakamotosan 2016年4月23日 (六) 01:33 (UTC)
  • (-)反对,这是为下次罢免乌拉/shizhao做准备?--CHEM.is.TRY 2016年4月27日 (三) 11:44 (UTC)
  • (=)中立:有建设性,但可能不具备操作性。Galaxyharrylion留言) 2016年5月1日 (日) 03:55 (UTC)

有關中立票是否應當計算有效票,如何計算[编辑]

拋開上方的提案不提,各位似乎就中立票是否應當算有效票有爭議。在下匯總了上方討論中有關中立票的意見,希望各位研討。

  1. 原條文與新條文之「總有效票數」是否有將中立票計入?
  2. 若上面屬實,則:
    1. 原條文是否將「中立票」與「反對解任票」置於同一地位?有何利弊?
    2. 新條文是否將「中立票」與「支持解任票」置於同一地位?有何利弊?
以上。-和平、奮鬥、救地球!留言DC14討論於 2016年4月20日 (三) 09:01 (UTC)
  • 中立票应当计入总有效票数,但只在支持票及反对票相同票数时,中立票附上的理据才会被考虑。
  • 中立票的投票人是须要符合人事任免投票资格,其地位不同于只可在意见区发表个人观点的IP及用户,因此其投票仍属参与该等人事任免投票的有效票。
  • 然而,中立票不应被自动视为支持或反对某一投票议案,因为中立票附上的意见是倾向支持或反对皆有之,意见并不一致,中立票往往是认同某一观点,但认为尚未须要执行该决议的程度。--Thomas.Lu留言) 2016年4月20日 (三) 10:35 (UTC)
    • WP:RFDA,人事任免投票资格并不适用于中立票。 --达师 - 334 - 554 2016年4月20日 (三) 10:38 (UTC)
Wikipedia:申请罢免管理员说“可以投支持票(同意罢免)或反对票(反对罢免)”,没有提及中立票。如有人投中立票,理应不计入有效票数内,不过我不反对在该方针内加入更明确的说明。--Mewaqua 2009年6月28日 (日) 11:30 (UTC)

--达师 - 334 - 554 2016年4月20日 (三) 10:50 (UTC)

  • 中立票被算入总有效票数有先例可循,见 Wikipedia:管理員解任投票/Mosesofmason/第2次#结果Wikipedia:管理員解任投票/Ws227/第2次#结果。 --Thomas.Lu留言) 2016年4月20日 (三) 10:56 (UTC)
    • 但门槛改为50%至今并未出现“支持票比反对票多,但计算中立票时支持不足50%”或“支持加反对不足25票,而加入中立票后总票数超过25票而解任案通过”的情况。或者简单来说中立票并没有起过作用。在Wikipedia:管理員解任投票/Shizhao/第4次#结果也有不要计入中立票的主张。 --达师 - 334 - 554 2016年4月20日 (三) 12:11 (UTC)
  • 中立票可视为出席该项投票,但不应划入支持或反对有关投票议案。--Thomas.Lu留言) 2016年4月21日 (四) 05:37 (UTC)
  • 应当和WP:RFA及中文维基百科其他常规投票相同处理,中立票视为弃权,不计入总数,也不参与数量比较。 --达师 - 334 - 554 2016年4月21日 (四) 13:24 (UTC)
  • 以前就回答过这个问题,由于投中立票者必须将原有的票删除,才能再投支持或反对,我觉得这很显然就已经承认中立票也是有效票。--7留言) 2016年4月21日 (四) 15:41 (UTC)
  • 我感覺到條件中立票應該能夠說明一些事吧。還有,范君這次亦有可能會出現上述情況吧...--|1233 | 有問題? 2016年4月24日 (日) 17:06 (UTC)

以上,希望各位借鑒。 --Innocentius留言) 2016年4月21日 (四) 19:15 (UTC) 注:此不是投票,離拿出一個可行的方案還早着呢。

新增:維基百科不是 的建議[编辑]

我建議在維基百科不是什麼的最後加上以下內容:


维基百科不是惡搞場所[编辑]

維基百科拒絕惡搞。如果你想惡搞,請到偽基百科,因為維基百科不是

  1. 盡情破壞的地方。雖然維基百科能夠給所有人編輯(已保護的頁面例外),但是給予所有人編輯的原因是基於維基的開放性,而非測試管理員的應變能力
  2. 惡作劇的地方。沒有理由的刪除與更改會影響其他人的瀏覽的資料的準確性,社會大大影響維基的可信度。
  3. 偽基百科。雖然偽基百科的設計與維基百科差不多,但是兩者出現的原因是完全不同的。

---1233有問題? 2016年4月21日 (四) 07:19 (UTC)

可是,編輯的時候,沒有看到什麼“Wikipedia:维基百科不是什么”之類的。- John doe 120留言) 2016年4月21日 (四) 08:58 (UTC)
看了頁面瀏覽統計,懷疑對於你的修改,絕大部分人看不到。- John doe 120留言) 2016年4月21日 (四) 09:10 (UTC)
Wikipedia:何谓忽略所有规则,其說編寫維基本來就不用先看規則,而是當其它人覺得你的編寫有問題時再給規則看的。--Liaon98 我是廢物 2016年4月23日 (六) 15:58 (UTC)
  • 「上醫治未病,中醫治欲病,下醫治已病」——《黃帝內經》 - John doe 120留言) 2016年4月26日 (二) 14:05 (UTC)
  • 此類比有誤。如我們在現實中,除了法律系的人外,是沒有人會把《六法全書》全看完的,大家憑著良知,基本上所作所為都不太會違法法律(因為法律本身就是建立在大家的常理和道德上),頂多犯一些通常只會被勸導或罰鍰的小錯誤(如交通違規)。Wikipedia:避免說明氾濫Wikipedia:何谓忽略所有规则都表明幾乎沒有人是會把維基百科上所有的規則都看過的,WP:規則只是原則維基不官僚也都表明,規則頁背後的眾人思想原則才是規則,而非這些規則頁所寫的內容。因此有人出錯再告知如何改進是遠比叫他們一進維基就看完上百頁的規則,來的有效率且有意義,且這樣才不會嚇走人--Liaon98 我是廢物 2016年4月27日 (三) 05:37 (UTC)
  • 不是,我的意思是新手需要瀏覽的規則太少。編輯維基的時候,新手會看到三處文字:
  1. MediaWiki:Editpage-head-copy-warn。它的第三句似乎允許IP用戶“任意”編輯維基
  2. MediaWiki:Previewnote。它是黑色字體,我這裡變成紅色錯誤,每次預覽時,要不遺漏地看一下
  3. CC-BY-SA — John doe 120留言) 2016年4月27日 (三) 09:13 (UTC)
  • 沒誤解你的意思啊,你給的那句話就是說,希望新人能先閱讀規則(先不論多寡),比出事再閱讀好。而我回你的意思就是,新人完全不用閱讀規則,等出問題再由老手告知,如此--Liaon98 我是廢物 2016年4月27日 (三) 13:09 (UTC)
已經有WP:MEMORIALWP:FORUMWP:VAN,我不認為有必要阿茂整餅。--春卷柯南-發前人所未知 ( ) 2016年4月21日 (四) 09:17 (UTC)
已有WP:破壞等頁,不太需要--Liaon98 我是廢物 2016年4月23日 (六) 15:58 (UTC)
与现有维基百科:坏笑话和删除的胡话冲突。--Techyan留言) 2016年4月24日 (日) 08:22 (UTC)
WP:-)跟上面的主張不相關吧。--春卷柯南-發前人所未知 ( ) 2016年4月24日 (日) 08:26 (UTC)
跟幽默頁面認真幹麼,既非方針指引可能甚至稱不上論述--Liaon98 我是廢物 2016年4月24日 (日) 12:14 (UTC)

建議更改管理員任免投票資格[编辑]

現時的管理員任免投票資格為:

1.解任投票聯署提出或上任投票開始1個月前,編輯100次或以上,並在聯署提出或上任投票開始前3個月內至少有一次編輯(不包括任何用戶頁及用戶對話頁);
2.編輯3000次或以上,或編輯1500次條目或以上。
符合其一者將會獲得投票資格。

現時,若有爭議,管理員會有以下規定:

抽出而交社群討論,並由行政員決定是否符合資格。不當取得投票資格者,如重複編輯或回退、屢刪屢加完整內容以增編輯數、大量無意義操作、多次提刪無版權問題頁面、編寫侵權或廣告等,其投票應抽出交社群商議判斷是否有意破壞,及作出適當處理。行政員凡基於事實及社群意向,均有權決定選票有效與否。

我認為,人事任免資格應該更嚴謹,並且更清楚,並應該改為以下

用戶在投票開始前須符合以下其中一項條件
1.解任投票聯署提出或上任投票開始1個月前,編輯100次或以上,並在聯署提出或上任投票開始前3個月內至少有一次編輯(不包括任何用戶頁及用戶對話頁);
2.編輯3000次或以上,或編輯1500次條目或以上,並在聯署提出或上任投票開始前1年內至少有一次編輯(不包括任何用戶頁及用戶對話頁)。
而且符合以下所有條件
1.在解任投票聯署提出或上任投票開始6個月內,並沒有受到封禁(不合理封禁除外);
2.用戶並不是機器人;
3.用戶當時擁有已定制的用戶頁面;以及
4.投票開始前1年內,有參與社群/對話討論 (不包括人事任免頁)

我不希望有人為了投票而投票,所以才希望提出更改守則,令資格的鑑定更清晰及減少爭議。--|1233 | 有問題? 2016年4月22日 (五) 03:36 (UTC)

討論[编辑]

下面的1234没必要,1.封禁不是惩罚用户,不应往后还要持续剥夺投票权。2.机械人从来都不可投票。3.是否编写用户页是用户的权利,不应因此而被剥夺投票资格。4.是否参与讨论是用户的自由,编辑条目都是贡献。

至于3000以上编辑,1500次以上的条目编辑,应最少6个月或1年有一次编辑或可考虑,像在下这类基本上以后不编辑,十年后(如情况许可)仍可以,甚至忽然参与人事任免投票,做法并不理想,但当时讨论投票资格时,有用户要求老用户不论何时都可以投票,这个现在不易修改。--Thomas.Lu留言) 2016年4月22日 (五) 03:54 (UTC)

1234无必要。--Antigng留言) 2016年4月22日 (五) 04:22 (UTC)
根本就很饒舌......如同樓上所言沒必要。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月22日 (五) 07:10 (UTC)
@Thomas.LuAntigng小躍:我純粹想澄清資格而已。還有,為何你會認為我是那些"以后不编辑,十年后(如情况许可)仍可以,甚至忽然参与人事任免投票"的人?范君的任命,我是沒有投票資格的--|1233 | 有問題? 2016年4月22日 (五) 08:44 (UTC)
修改投票资格乃兹事体大之事,除非现在已有众多用户表态认为须要修改投票资格,否则这类讨论通常都会无共识存档。至于长期没有参与中文维基,又可以忽然参加投票,虽然在下认为自己因长期没有参与贡献而放弃投票问题不大,但毕竟会对不少有更多编辑数的用户有一定影响,他们甚至认为既有的投票权被剥夺,因此增加条款必须有明显共识,但目前时局应难以达成共识,反正也未见有逼设修改的须要。--Thomas.Lu留言) 2016年4月22日 (五) 10:35 (UTC)

投票[编辑]

李博翔 存廢覆核制度?[编辑]

這個條目之前被提刪過(2014年)! 這幾天被人重新創建,被提刪的條目創立 照程序不是應該經過存廢覆核才可以創立?如果沒有應該可以提g5速刪? 為啥可先創立後再去考量關注度的問題??就算是關注度問題也應該走 存廢覆核去處理吧? 怎麼用會以相同理由(關注度)去討論存廢? Zenk0113留言) 2016年4月22日 (五) 04:20 (UTC)

查了記錄之後發現新建的條目內容與當初被提刪的內容不完全相同,像這樣的條目重建方式並不需要經過存廢核覆(存廢核覆應該是針對一模一樣的內容想要取消刪除時的情況),如果覺得人物還是有關注度不足的問題也還是可以再送關注度審查,但不適合速刪處理。還有,關注度(尤其是藝人的關注度更明顯)是會隨時間改變而變化的,兩年前默默無聞沒啥關注度的人物,不表示兩年後還是一定會一樣關注度不足。--泅水大象訐譙☎ 2016年4月22日 (五) 08:50 (UTC)
  • 除非重建的条目内容与先前大部分相同,否则不应执行G5速删。此外,目前没有规定条目必须在存废复核恢复,如果编者认为其重建的条目能够符合当前的关注度等收录准则,是可以直接重新编写。如果某编者多次建立不符合收录标准的页面,有关编者或会被视为扰乱而限制其编辑,或该条目名被保护防止多次重建。--Thomas.Lu留言) 2016年4月22日 (五) 11:01 (UTC)
  • 在下于存废讨论建议暂时保留李博翔,是因为提删理由是宣传,而条目有来源,又已挂上关注度模板,基于宣传语调不明显,所以走流程再次关注度鉴定更合适。除非条目涉及明显宣传、破坏性或确定内容与先前被删除版本大部分相同,否则应善意推定,容许编者有时间改善条目,在存废讨论也能以关注度再次审查其是否适合收录。如果先通过AFD,AFD又把关良好,是有助减少DRV的压力,避免什么都掉到只有少量管理员处理和判断的DRV。--Thomas.Lu留言) 2016年4月22日 (五) 11:01 (UTC)
  • 重複的事情一再發生。前陣子香港演員許碧姬才被今年的新管理員Antigng直接以G5快速刪除。我打開檢查被刪除版本,發現內容與舊版完全不同,不適用G5。李博翔是被保留下來了,許碧姬則被管理員刪掉了。--Jasonzhuocn留言) 2016年4月23日 (六) 04:58 (UTC)
了解! 本來以為提刪條目一定要經覆核機制才能夠重新建立!感謝各位說明 Zenk0113留言) 2016年4月23日 (六) 09:37 (UTC)
不過普通使用者也看不到被刪版本,他們只知道曾被刪過;這樣應當速刪(讓管理員看被刪版本決定)還提刪?--Liaon98 我是廢物 2016年4月23日 (六) 11:30 (UTC)
机械性地直接提报G5,然后管理员又机械性地执行删除,在DRV条目却因为不符合G5而复还,不是理想的处理方法。根据WP:CSD - G5:如果提刪者對此不肯定,請先聯絡上次執行刪除的管理人員。快速删除主要针对明显不适合收录的条目,即是这些条目的删除是符合WP:SNOW,包括条目的内容大部分与被删除版本相同,或质量更低劣,例如条目仍是没有任何来源。如有怀疑或不肯定,应先提报关注度或AFD,以便更多用户参与处理其存废。--Thomas.Lu留言) 2016年4月23日 (六) 13:48 (UTC)

十八禁條目提醒[编辑]

中文維基有無提醒十八歲以下人士應謹慎觀看的模板?另:我一直不明白爲何要將AV女演員拍攝過的「招式」寫出。(笑)--地底深山留言) 2016年4月22日 (五) 10:24 (UTC)

日語維基百科一條目有兩個提示模板。不知中文有無?--地底深山留言) 2016年4月24日 (日) 19:44 (UTC)
除了醫學警告模板外,其他聲明模板在過去的討論已經都刪掉了,不在條目中警告和聲明--Liaon98 我是廢物 2016年4月24日 (日) 19:46 (UTC)
那麼各位覺得日語維基百科這個條目隱藏圖片的方法可不可取?如變態 (色情用語)一文的色情圖片我覺得有隱藏的必要。--地底深山留言) 2016年4月24日 (日) 20:12 (UTC)
以前早就討論過了,結論就是不審查內容、不隱藏內容。除了醫學警告最後有留下外,其他都沒留下。--Liaon98 我是廢物 2016年4月24日 (日) 20:15 (UTC)
感觉是不是脑子有问题?已经提到不做内容隐藏或警示,还自说自话地问着,还举着ja做例子。语文还得在学习一下。总之,不对内容进行非方针要求的审查,也不因此隐藏内容。——路过围观的Sakamotosan 2016年4月25日 (一) 02:07 (UTC)
  • 請不要激動。是我沒有把那個方針理解透的緣故。--地底深山留言) 2016年4月25日 (一) 10:10 (UTC)
別一上來就罵人腦子有問題啊@@ 話說變態那個條目當初DYK入選,甚至是拿那張圖上首頁的--Liaon98 我是廢物 2016年4月25日 (一) 02:40 (UTC)
任何维基百科项目都设有图片黑名单,这可以阻止绝大多数正常条目被破坏性地加入不正常图片。但是在“变态”条目中限制使用不变态的图片就太说不过去了。--Antigng留言) 2016年4月25日 (一) 04:40 (UTC)

有關解任程序的方針的更改提議[编辑]

原因:我近日看見在在范君的解任投票時出現了一些問題,因此我有以下反思:
我認為那是因為解任程序本身出現了問題,因此我希望修改解任程序,減少灰色地帶,以減少玩弄維基規則,及改善罷免的程序。 我的提議如下

提議[编辑]

註:粗斜體為新增的內容,橫線為刪除的內容

  • 提出:由一名有投票资格的用户自動確認用戶提出解任管理員申請,並說明理由。提出解任管理員申請後,必須隨即在該管理員的用戶對話頁留言通知(可使用{{NoteforRFDA}})。
  • 條件:申请必须在事件发生48小时之后才能提出,在这段时间裡当事人之间应该尽量沟通。只有在沟通无效的情况下才可以发起取消管理员权限的投票。內容必需詳細,指出管理濫權的原因,並根據編輯記錄及用戶貢獻提出相關證據,如內容不符或原因不合理,可視作申請無效。為了防止一案多審,除非有新證據出現,否則不得就同一事件重覆提起解任。
  • 聯署:7日內,必須收集7名或以上有投票资格的用户联署,用户可以在互助客栈提出解任的意向,并徵求联署人。在有七位有投票资格的用户滿7人聯署後解任案方為成功提出。一旦七位用戶的資格被確認後收集到7名联署人便會立即进入下一阶段。7日後仍未有足夠聯署者,被提解任人無須答辯,解任案自動失效。
  • 答辩:在解任提出后,被解任人有5天的答辩期,对于解任申请中指出的问题进行答辩。在答辯期間,不得提出新的指控。若果你認為這個指控是十分重要的,請聯絡其他管理員,並填上原因。若果其他管理員同意增加原因,答辯期將會重新計算。如果解任人在5天内没有答辩,被视为无答辩意见,不過仍可在投票期間發表意見。
  • 投票:答辩期过后,进入投票程序。投票期为14天,符合人事任免投票資格者(包括被解任人)可以投支持票(同意解任)或反对票(反对解任),也可以在讨论区发表意见,无论支持票还是反对票,投票人需给出理由。联署人自动计为支持解任,但仍可以在投票期间改变意向。用户可以在投票期内改变立场,结果以投票期结束后为準。重复投票和傀儡投票将被视为无效票。
  • 結果:有效表決的最低總有效票數為25票。如總有效票數低於25票,則不論結果如何,均視為解任案不通過。若總有效票數達25票或以上,且支持解任票數超過50%者,則投票通過。惟懷疑投票結果被作弊,可由行政員討論決定該次投票是否有效。若有其它不恰當行為嚴重影響,又或投票程序出錯,而指控者(指控者可以是任何人)能夠讀出確實的證據,必須重新開始投票程序。,此重新開始的程序將會繞過解任投票第三部的第一個程序。可由行政員討論決定該次投票是否有效。
  • 收回权限:投票结果为解任时,由行政员将社群的共识提报给元维基,申请收回该管理员的权限。

以上純屬個人意見。--|1233 | 有問題? 2016年4月22日 (五) 16:19 (UTC)

討論[编辑]

由於目前正有解任投票进行中,关于解任流程规则的修订,应在当前投票结束并有最终决定后再议。即使这类讨论不应影响当前投票,但解任流程的修改属于对规则的重大修订,必须有足够讨论、进行公示及投票等程序,以便取得社群的多数共识。然而当前解任投票的投票者,及将要处理投票的人员都须要考虑避嫌,避免被质疑尝试影响当前解任程序的结果,令这类涉及解任规则修订的提议会难以获得充分讨论。--Thomas.Lu留言) 2016年4月22日 (五) 19:47 (UTC)

建议逐一通过,以免个别争议修改影响本可以通过的修改。以及,这次修改不应影响已开始的解任讨论。 --达师 - 334 - 554 2016年4月23日 (六) 10:15 (UTC)
解任程序是环环紧扣,即使只是修改其中一个程序的规则,因为关乎管理员的人事任免,所以仍属重大修改,基本上仍要讨论,制定草案,公示及投票,不能在客栈部分用户说说就可以修改这类任免程序及规则。--Thomas.Lu留言) 2016年4月23日 (六) 13:56 (UTC)

根据最近的争议,我觉得还有必要明确两点:

  1. 普通用户有无自行认定他人的解任提议是扰乱并强行删除的权利。(我觉得对于符合投票资格用户发起的讨论,反对方在讨论中可以提异议,但不能强行删除。)
  2. “一案多审”的认定应该从何时计算。我认为按照法理及实际可操作性,应该以联署成功后方可认为进入“审”的流程。即在未通过的联署及讨论中提及的证据,仍可被用于将来的指控。否则,任何管理员犯了个错误以后,都可以找个人提一下罢免,然后用很诡异的理由使社群无法认同罢免,以规避将来的指控,--Miao233 RBEEPE 1IPBEGIPBE留言) 2016年4月24日 (日) 12:33 (UTC)

意見[编辑]

向中文维基百科引入编辑审核制度[编辑]

前言[编辑]

有用户在维基百科的 Telegram 频道上提到了在中文维基上引入编辑审核Pending Changes )制度,同时鉴于前两次有关引入此制度讨论都是在数年前进行,现在中文维基的状况已经有了一些改变,因此在下决定在互助客栈中重提一次有关引入编辑审核制度的讨论。

简而言之编辑审核制度即在维基百科上的部分条目实施先审核后发布的制度。

大多数用户对被编辑审核保护的条目(在之前的讨论中被称为“待审保护”)的编辑都会被一种叫 pending changes reviewer (译名待定,在之前的讨论中被称为“审查员”“审核员”等)的用户审核,经过审核之后方能发表。因此如果引入这一制度,会需要在中文维基上新加入 reviewer 这一权限。这一权限的申请与巡查权、回退权等类似,但三者并不相关。请各位参考维基百科:编辑审核上的内容。

在之前的讨论中,有一些用户可能误会了编辑审核制度初衷。而目前中文维基上有关编辑审核的方针翻译工作尚未开始,因此在下先对这一方针在英文维基的大概使用方法做一些概括:

  • 在英文维基上,编辑审核与半保护、全保护等视作一种保护状态。因此被编辑审核保护的条目同样需要在受到破坏之后方能实施。见Wikipedia:Protection policy
  • 被保护的条目分两类:Pending Changes Level 1(在之前的讨论中被称为“乙级待审保护”)和Pending Changes Level 2(在之前的讨论中被称为甲级待审保护)。被 Level 1 保护的条目允许自动确认用户和确认用户编辑后无需审核直接发布;被 Level 2 保护的条目即使是自动确认用户和确认用户编辑后也需要审核。但在英文维基上, Level 2 仍有较大争议,极少使用。
  • 大多数被待审保护的条目都是生者传记条目。在之前的讨论中,很多中文维基人没有意识到这一点。编辑审核的主要保护对象并不是具有巨大争议的、编辑十分频繁的条目;也不是有两名维基人发生编辑战的条目。一般对这类条目的改动比较少,因此待审核的编辑数量不是特别多。在英文维基上,规定需要待审保护的条目为以下三类:
    • 被长期性破坏的条目;
    • 对传记或生者传记条目的破坏;
    • 侵权破坏(向已创建的条目中加入侵权内容)。
  • 待审核条目的记录是完全公开的。这个记录包括了
    • 某名用户在何时递交了需要审核的编辑,其内容为何;
    • 审核这一编辑的 reviewer 是谁,通过了或者没通过(没通过的审核也不会被类似 RRD 的方式隐藏,在历史记录中可以直接查看);
    • 若一个条目有需要审核的编辑,那么任何人可以直接查看,但默认显示的不是待审核的编辑。

试举一例:SpongeBob SquarePants (season 9)。该条目似乎是因为被加入了大量侵权内容而被待审保护。在这一条目右上角的 Edit 标签处,还有一个 Pending Changes 的标签。如果有人递交了待审核的编辑,那么无论任何人都可以直接点 Pending Changes 这个标签查看,但是默认看到的却不是待审核的编辑。搜索框下面有 Accepted 的字样,右面还有表示 pending changes protection 的小锁头,表示该页面正在被待审保护。在该页面的历史记录页( History ),可以直接看到该条目所有的审核记录。

因此,待审保护不必过度担心会造成新用户流失、过度集权于管理员和 reviewer 的情况。

在这里整理了英文维基上有关编辑审核的方针和指引。请各位参考。

Techyan留言) 2016年4月23日 (六) 15:32 (UTC);修改于2016年4月23日 (六) 15:44 (UTC);修改于2016年4月24日 (日) 05:43 (UTC)

討論[编辑]

  • (-)反对,见Wikipedia:互助客栈/方针/存档/2015年9月#第3遍了:编辑审核--Antigng留言) 2016年4月23日 (六) 15:36 (UTC)
    • (:)回應@Antigng:我似乎没有看见您在2015年9月的讨论中发表具体的反对意见。除此之外,我对之前讨论中的误区做出了解释。--Techyan留言) 2016年4月23日 (六) 15:44 (UTC)
      • 主要是其它用户的意见,比如“我看了一下其他版本的自動審查員,發現那編輯審核不見得會有成效,倘若有心人濫用,那不就更邋塌”--Antigng留言) 2016年4月23日 (六) 15:53 (UTC)
  • (+)贊成完全只是觉得有“0.75保护”的必要性。┌─⚡⠠⠵[learningis1st]-[~]- time = 2016年4月23日 (六) 16:33 (UTC)
  • (+)支持:做為一個介於半保護與全保護之間的保護狀態有何不可?說實話,有時破壞真的防部慎防,對於部分條目進行編輯審核制對於破壞處理可能會更有效率--宇帆(留言·) 2016年4月23日 (六) 16:52 (UTC)
  • 如果是明显破坏回退或移除便可,中文维基搞审查只会徒增争议。谁来当审核员,尤其大量涉及政治的条目,例如中共统治、台湾政治、六四、法轮功、占中、中日军事与外交、中国对外主权争议,双方都自认中立,认为对方扰乱。审核员本身也难以获得公信力,甚至被批为政治打手,又或被质疑修炼法轮功,审核员肯定远比管理员还难当得多。这样干不但无助提升品质,反而带来更多争吵,更令中文维基因此被贴上政治审查的标记。--Thomas.Lu留言) 2016年4月23日 (六) 17:04 (UTC)
  • 编辑审核条目主要保护的对象(以生者传记条目为主)可以看出,编辑审核主要是为了防新手、脑残粉和小粉红之类的而不是用来调节用户(尤其是老用户)之间争议的。对于老用户之间的争议,应该使用全保护来解决。而法轮功、六四事件等条目也不是编辑审核所保护的对象。待审保护和半保护、全保护可以同时实施,相互之间不冲突。相比较之下,现在中文维基人手较缺,对于编辑不是很频繁的一些条目来说,实行编辑审核更容易把握条目质量、避免条目被破坏还长时间无人发现的情况。在制定方针的时候要严格规定编辑审核适用的条目类别。--Techyan留言) 2016年4月23日 (六) 22:00 (UTC)
  • “这些条目很有可能被破坏,因此即使没被破坏也要提前保护。”,这个出发点就是不正确的。--Antigng留言) 2016年4月24日 (日) 03:26 (UTC)
    • @Antigng:都說是受到破壞再經由Wikipedia:请求保护页面來對特定頁面實施編輯審核制了。。。。。。。。--宇帆(留言·) 2016年4月24日 (日) 05:54 (UTC)
      • [3]--Antigng留言) 2016年4月24日 (日) 05:56 (UTC)
        • @Antigng:那麼就用『受到破壞再經由Wikipedia:请求保护页面來對特定頁面實施編輯審核制』這種運作方式來引入編輯審核制不就解決了?--宇帆(留言·) 2016年4月24日 (日) 05:58 (UTC)
          • 这样又会推出“这个机制没有用”的结论。如果“受到破壞再經由Wikipedia:请求保护页面來對特定頁面實施編輯審核制”,我们有已经有半保护,有全保护,有{{editprotected}},为什么还需要pending changes review?--Antigng留言) 2016年4月24日 (日) 06:02 (UTC)
            • @Antigng:就只是跟┌─⚡⠠⠵[learningis1st]-[~]的想法差不多,覺得要有一種介於半保護與全保護之間的一種保護--宇帆(留言·) 2016年4月24日 (日) 06:04 (UTC)
              • 不是“覺得要有一種介於半保護與全保護之間的一種保護”,就需要引入这么一种东西。你需要表明有什么问题现有的制度不能解决,而引入新制度以后能够解决。--Antigng留言) 2016年4月24日 (日) 06:10 (UTC)
                • 我認為對於『條目遭到破壞沒有即時看到,而該破壞若造成合理使用圖像無法顯示會造成合理使用圖像被提交快速刪除』這種搞的人很煩躁的破壞可能可以解決--宇帆(留言·) 2016年4月24日 (日) 06:16 (UTC)
                    • 这通过半保护没法解决吗?--Antigng留言) 2016年4月24日 (日) 06:19 (UTC)
    • @Antigng:我看了您的留言,又回去看了英文维基的方针。Pending changes portection should not be used as a preemptive ueasure against violations that have not yet occured. 我刚开始自己看错了,还有问题吗?--Techyan留言) 2016年4月24日 (日) 06:54 (UTC)
      • 如果承认了pending changes review不是预防措施,就会推出“这个机制没有用”的结论。--Antigng留言) 2016年4月24日 (日) 08:25 (UTC)
  • (+)支持編輯審查制度,這個用好了會有很大幫助,但是重點在於要用在哪裡。-- 給我留言 「歡迎加入 #cvn-zh-scan Qinyongr 2016年4月24日 (日) 08:18 (UTC)
    • 用在哪里都不知道如何“用好了會有很大幫助”?--Antigng留言) 2016年4月24日 (日) 08:25 (UTC)
  • (-)反对:我的想法跟Thomas.Lu差不多,中文維基人手不足,且觀點具有極大分歧,這個審查容易失中立;我認為現在的全保護、半保護就很夠用了。有些事情還是討論比較好,而不是交由審查員判斷--Liaon98 我是廢物 2016年4月24日 (日) 12:17 (UTC)
  • 看起來和WP:穩定版本有點相像,可以先研究研究。--Jasonzhuocn留言) 2016年4月24日 (日) 13:26 (UTC)
    • 我一开始也把这个制度和稳定版本搞混了,然而事实是这个和稳定版本是两个完全不同的制度。Bluedeck 2016年4月27日 (三) 06:42 (UTC)
      • @Bluedeck:我看了一點PC的文檔,還沒充分理解怎麼回事。--Jasonzhuocn留言) 2016年4月27日 (三) 11:29 (UTC)
  • 我不很支持。首先看壞一點這東西可能會變成變相審查,其次要找個持平的審查員是一個問題,再來就是英文版社群比我們更加老成(Wikimedia-I的討論有90%都不想理),要小心這東西在這兒會變質。如果要籠統的說說我的憂慮,我會用「不符合國情」來形容。--春卷柯南-發前人所未知 ( ) 2016年4月24日 (日) 13:32 (UTC)
  • (+)支持我建议部分非政治条目采用这个措施来保证条目质量。--Herfjotur留言) 2016年4月25日 (一) 05:19 (UTC)
  • (!)意見这个方法目前在个别维基使用,主要有英文式和德文式,英文式就是部分条目进行pending changes。德文式,包括按照德文维基为模板建立的文言维基,只要有一遍review之后,每个变化就必须再次进行review。这些维基有一个职位就是用于review的。以上供参考----損齋留言) 2016年4月26日 (二) 01:19 (UTC)
  • (!)意見,如果真要引入,只考虑在FA、GA这两类容易涉及质量破坏的条目使用,这样可以避免因为两岸相关政治倾向而引起争议而陷入政治审查的圈套。当然,实际上这种前审核其实就是百度百科的模式,这样和我们这里一旦提交就可立即显示的理念不符,反而更需要加强对破坏的发现和处理的手段和行动,而非靠前审核这种容易引起争议的手法。——路过围观的Sakamotosan 2016年4月26日 (二) 02:27 (UTC)
  • (-)反对:沒必要加入編輯審核制度。--Engle躍築夢踏實夢想起飛‎安裝文字動畫效果】 2016年4月26日 (二) 07:23 (UTC)
  • (-)反对,以目前中文維基百科生態,不建議加入編輯審核--Wolfch (留言) 2016年4月27日 (三) 01:17 (UTC)
  • 偏向(+)支持。这个制度不是事后审核制度。制度本身也十分聪明,为保护提供了更多弹性。如用在冷门和长期破坏的条目上,将会达到其希望的效果。唯独考虑到中维处理争议的水平和处理积压工作时间,担心采纳该制度会--1,在引入复杂性的同时不能带来相应的效率提升。2--,Pending changes的冷门天性可能会令其积压时间超过半保护措施。故仅有保留的支持。Bluedeck 2016年4月27日 (三) 06:40 (UTC)
    • 到時候每次編輯幾乎需要審核員和管理員審核......好用嗎?閣下可以去test.wikipedia.org或test2.wikipedia.org去用用看就知道了--Engle躍築夢踏實夢想起飛安裝加速投票工具】 2016年4月29日 (五) 08:08 (UTC)
  • (?)疑問,請問現在有甚麼維持保護冷門條目的有效機制?--老陳留言) 2016年4月27日 (三) 21:19 (UTC)
    • 没有,也不应该有。--Antigng留言) 2016年4月28日 (四) 02:14 (UTC)
  • (-)反对--當前中文維基生態,並不適合,將衍生很大的爭議問題。Wetrace歡迎參與人權專題 2016年4月29日 (五) 11:55 (UTC)
  • (-)反对:從WP:PC的表格來看,與半保護和全保護的性質過於類似,沒必要再多出编辑审核制度。--M940504留言) 2016年5月1日 (日) 03:39 (UTC)

论述[编辑]

讨论已经进行了一周,收获了不少意见。下面在下想对遇到的反对意见做一些解释。希望各位能认真读完

  • 编辑审核不是审查而是保护。编辑审核在本质上与百度的先审核后发布的政策不同。
  • 编辑审核不会影响普通用户的编辑。绝大多数情况下,确认用户不会受到编辑审核的影响。需要进行编辑审核的只包括了 IP 用户和非确认用户。也就是说,普通用户编辑战仍需要通过全保护解决。
  • 编辑审核不适用于争议性强的条目。在下在前面已经提到过:编辑审核通常只适用于传记类、长期破坏类和长期被添加侵权内容类。解决法轮功、六四事件之类争议条目不会使用编辑审核功能。在社群讨论实施细则的时候,可以对适用的条目类型做出更明确且更严格的规定。
  • 编辑审核造成的积压并不严重。英文维基的这一页面中,待审核的条目数量不多,且时间跨度很大。被保护的条目大多比较冷门(大约一周到数周才会发生一次新用户的破坏编辑)由此可见积压完全在可接受的范围之内。
  • 对 reviewer 的要求并不是很高。根据在下在 Huggle 上的经验,对最近更改的明显破坏很好判断。Reviewer 这一权限与巡查权和回退权类似,不必太过担心缺人。当然有关具体的要求还待社群之后讨论。
  • 不是每篇条目都需要进行审核。作为一种保护,编辑审核同其他类型的保护一样,只在发生破坏后保护需要保护的条目。
  • 编辑审核完全透明。任何人(包括新用户)都能在历史记录里看到该条目 review 的记录。包括递交的新版本、reviewer 是谁、该版本通过与否等。新用户也能知道自己的编辑正待审核。
  • 编辑审核以 level 1 (乙级待审保护)为主。 Level 2 (甲级待审保护)存在但是很少使用。在英文维基上 level 2 保护曾引起很大争议,现在几乎没有应用。

那么,什么样的条目适用于编辑审核?编辑审核是否与现有的半保护和全保护冲突?

在下认为,编辑审核是一种部分替代半保护的保护措施。当我们对条目实施半保护的时候,阻挡了有害的编辑,但是也阻挡了想要对该条目进行建设性编辑的用户。尤其是在一些被永久、或者长期半保护的条目上。相比较半保护,编辑审核更像“ 0.25 保护”。编辑审核更宽松、更适合长期保护、更不容易影响新用户的编辑。翻开 WP:VIPWP:PT ,相比半保护而言更加适合用编辑审核的条目更多。试举两例:

  • 日本人条目长期被不同的 IP 用户破坏。如果实施编辑审核,可以延长保护期限,避免待保护结束后继续有人破坏;也能避免阻挡新用户的编辑。
  • 智利长期被来自智利的不同的 IP 用户和新用户加入机器翻译内容。现在被永久半保护,如果实施编辑审核,可以避免新用户的编辑被阻挡。

实际上,很多在 WP:PT 上的被永久或长期半保护的条目更适合编辑审核。半保护会一刀切地阻断所有新用户的编辑,而无论是否具有建设性。而永久半保护则会永远地阻挡所有新用户的贡献。这些条目大多都是长期被不同的新用户破坏、且还有新用户做出建设性编辑的。

那么半保护是不是就没用了?有些条目更适合在短期内半保护,而对于高风险模板之类的页面,永久半保护更加合适。

@AntigngThomas.LuChenyijia001QinyongrJasonzhuocn:@Liaon98A2569875小躍春卷柯南Herfjotur:@三石樑桂老Cwek老陳WetraceM940504:请诸位发表意见。

Techyan留言) 2016年5月1日 (日) 14:38 (UTC)


香港人的國籍[编辑]

本文在討論香港人國籍問題,基於澳門人的法規更簡易及寬鬆,所以不一定適用於澳門人

按照香港基本法全文,尤其「文件十五」的內容,香港在實施《中華人民共和國國籍法》時考慮到香港的歷史背景和現實情況,有特別的執行方法。

自1997年7月1日主權移交時起:

  1. 有中國血統的香港居民出生於則具有中國公民身份
  2. 香港居民中的中國公民如擁有其他國籍者中國不承認但可以保留,即該人可保留有原有外國國籍及同時擁有中國國籍
  3. 「香港永久性居民中的中國公民」在中國行政機關上以「中國(香港)公民」區分出來

1997年7月1日前及後都適用:

  1. 香港雖然一直有以宗主國名義發放自己的護照的權力,但「香港」從來並不是國籍
  2. 「香港」並不是國籍,但「香港永久性居民身份」是一種獨立的「公民權身份」
  3. 英國國民(海外)一種英國國籍,即使沒有任何地方的永久居留權,仍是一種終身有效的國籍;正如「中國(香港)公民」沒有中國大陸的永久居留權,但「中國(香港)公民」是「中國公民」

有問題歡迎提問。--摩卡·賀昇 2016年4月26日 (二) 04:01 (UTC)

我的建议还是一样,慎重行事,然后去客栈讨论一下。我感觉此条款在此处不适用,是,条文上有这个,很多人一早都知道吧,这条指的是BNO的情况,但这里并不是。且,如果真的有效而且属于说话算数的情况下的话,那就不会发生最近的铜锣湾书店事件了,嘛,你知道我在说什么的。--我是火星の石榴留言) 2016年4月26日 (二) 09:37 (UTC)
可能有一些朋友因其國家法律上訂明雙重國籍是刑事罪行而不明白雙重國籍的操作。涉及:
  1. 1930年海牙國籍法公約有一條款為雙重國籍者不得在其中一國籍所在國家享有另一國籍的外交豁免權及領事保護權
  2. 香港基本法文件十五寫明香港的中國公民在香港不得享有英國的領事保護的權利
然而,一名人士是否擁有領事保護的權利,不代表他的國籍有否失去。銅鑼灣書店事件中的李波,由於他有中國血統,其中國國籍身份在回歸時生效,而其原有國籍英國是允許雙重國籍,故此李波是中國(香港)公民及英國公民。「首先是中國人」一說則是中國政府表明李波為中國公民且不可在香港享有英國的領事保護的權利。李波的國籍問題在現在法例下非常清晰。摩卡·賀昇 2016年4月26日 (二) 10:14 (UTC)
另外,由於香港基本法文件十五第四條已寫明生效於外國國籍,即包括而不限於英國各種國籍。摩卡·賀昇 2016年4月26日 (二) 10:20 (UTC)

关于WP:监督一问[编辑]

监督员查阅被监督隐藏的编辑历史是否会像查CU一样留下日志记录?--Xxss5566留言) 2016年4月27日 (三) 13:18 (UTC)

  • 当然会啊,否则还得了。--Antigng留言) 2016年4月27日 (三) 13:20 (UTC)
    • 好像不會吧。那根管理員查閱已刪貢獻是一樣的。--Qinyongr 給我留言 」「歡迎加入 #cvn-zh-scan 2016年4月27日 (三) 13:29 (UTC)
      • 看错了,我以为问的是执行OS的动作。--Antigng留言) 2016年4月27日 (三) 13:30 (UTC)

关于侵权检查[编辑]

昨日User:Jasonzhuocn给我留言,说我做侵权处理的时候“直接編輯了侵權條目,再將侵權版本隱藏”,这样“管理員直接改寫,其他用戶也會照做,試圖在七天之內直接改動被Copyvio模板覆蓋的條目”。但是我的观点是侵权检查的目的是移除侵权内容,不是惩罚用户,如果不是所有版本全文侵权,应当直接移除侵权的内容然后隐藏所有涉及侵权的版本,不需要整个儿删除。不知大家的观点如何。另见去年的讨论

--Antigng留言) 2016年4月30日 (六) 06:05 (UTC)

  1. 往中文社群好像未曾討論過要保留侵權者的署名權,通常是給改寫的人依參考文獻進行改寫之後,讓改寫者成為條目的創立者。可以討論下是否要改用新的做法。
  2. 在沒有達成共識之前,用新方法改寫,其他管理員認為你是錯誤操作。有人就說看了你的做法覺得很生氣,你卻說本來就應該這樣處理。我一時之間也不知道你的「本來」是怎麼來的,以為你發明了方法。我後來才知曉去年有個討論,但是還沒達成共識。
  3. 既然還沒成規則,先來討論比較妥當。否則容易被投訴。
  4. 我也通知了RalfX前來討論。--Jasonzhuocn留言) 2016年4月30日 (六) 06:45 (UTC)

哪个条目? --达师 - 334 - 554 2016年5月1日 (日) 12:54 (UTC)

自动清理尺寸过大的合理使用图片[编辑]

之前的讨论沉了。现在再次征求大家的意见,是否同意按照英文维基百科的公式\text{new width} = \left\lfloor\sqrt{\tfrac{\text{target pixel count} \times \text{original width}}{\text{original height}}}\right\rfloor清理这些超标的文件。

根据这样的标准,2169位用户上传的17120张图片将被缩小。--Antigng留言) 2016年4月30日 (六) 09:20 (UTC)

合理使用图片多大才算“过大”,其实并无定论。如今随着显示设备的技术提高,图片的分辨率普遍越来越高,10万像素的标准未免过于苛刻,建议适当放宽。例如,英文方针建议使用屏幕截图分辨率不超过320 × 240,但实际上如今的大部分软件和游戏截图缩小到该分辨率下,基本要素几乎都看不清了。—Chiefwei - - ) 2016年4月30日 (六) 09:57 (UTC)
  • (-)反对:認同User:Chiefwei看法,況且要考量有些是含中文文字圖檔,若縮小其辨識度會比英文差、看不清楚就沒有參考價值了。要適用本地方針而不要一味引用英文維基。--Justice305留言) 2016年4月30日 (六) 12:49 (UTC)
  • (+)支持,可以的話更應該收緊標準,為保障原作者權益,版權圖片可以看到基本的形態就夠了,不要為了高解像裝置而放寬標準,而且更應該積極地阻止讓高解像裝置細緻地觀看版權圖片。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2016年4月30日 (六) 10:05 (UTC)
挖了一副我传的,超宽的File:HTF_characters.png然后看了一下320,简直像鸡巴一样小。所以表示怀疑,可以参考来调整,但有些不能搞得太过分。——路过围观的Sakamotosan 2016年4月30日 (六) 11:02 (UTC)
我就只是看到说像鸡巴一样小所以点进去看了一下图片……--7留言) 2016年4月30日 (六) 13:27 (UTC)
谢谢较真,算了一下,接近500px宽,还算可以。320的话,就真像鸡巴一样。(笑)——路过围观的Sakamotosan 2016年4月30日 (六) 13:50 (UTC)
我也不明白size和判断算法,例如我以前上传过一批TH的开始界面截图,首先部分size的值和实际显示要高,其次居然同样规格的图中,有一幅是没有问题的。有点搞不懂。——路过围观的Sakamotosan 2016年4月30日 (六) 11:13 (UTC)
就是长和宽乘在一起。--Antigng留言) 2016年4月30日 (六) 12:42 (UTC)
  • (-)反对:若相片縮小其辨識度會比、看不清楚就沒有參考價值了,特別是歷史照片及海報。收緊標準只令維基百科走向衰落--Wpcpey留言) 2016年4月30日 (六) 13:20 (UTC)
  • 我怀疑你的统计程序有问题,居然还漏算了这个File:東方非想天則_〜_超弩級ギニョルの謎を追え.png(如果以10万像素为目标的话)。另外我觉得应该考虑这样的算法,是先最长边缩少至固定的长度(比例长度加底限长度),然后在插值放大回原有比例,这样同样也能达到降低分辨率,而且避免因为限制总像素而导致部分过大的图片被过度缩小。——路过围观的Sakamotosan 2016年4月30日 (六) 13:36 (UTC)
给个标准试试,长边按比例缩小至三分之二,不低于500px。看看效果。进入缩放图源,改一下宽值就可以实时看到结果。——路过围观的Sakamotosan 2016年5月1日 (日) 09:59 (UTC)

關於互助客棧過長討論串問題[编辑]

剛剛我在線下與其他用戶提到一個方案,就是說假設客棧上一個討論串長過一個長度就另開新分頁,留個連結在客棧上。這個方案的優點在於,想參與討論的自己去參與監視,不想參與的也不會被煩,VP也不會因此太長,更不會干擾到其他議案的進行。User:Carrotkit表示支持,User:BowleerinUser:Techyan也表示支持,只是需要具体细节。不知各位的意見如何?-和平、奮鬥、救地球!留言DC14討論於 2016年4月30日 (六) 13:10 (UTC)

當年過500000bytes還沒有這樣做,當有頁面再到了這個數字再討論吧。--Temp3600留言) 2016年4月30日 (六) 14:52 (UTC)
當年沒這麼做,不代表不需要這麼做。何況有些太長的討論已經被許多用戶抱怨干擾到其他討論的正常進行了。-和平、奮鬥、救地球!留言DC14討論於 2016年4月30日 (六) 14:58 (UTC)
方针版本来是供用户提出討論維基百科的政策及方針,不应被 Bluedeck 与 Galaxyharrylion 用来进行用户间的斗争,其争论明显不是以修订方针指引为核心,他们的一大串个人声明、争论已经占去本页不少篇幅。剔除这些与维基政策方针无关的讨论后,其实本页与过往相比并不算长。--Thomas.Lu留言) 2016年4月30日 (六) 17:14 (UTC)
我這個方案並不是單純針對方針版,亦非只針對某次個案。事實上,之前好幾次在條目探討版或者其他版的大篇幅爭論我早想這麼做了。-和平、奮鬥、救地球!留言DC14討論於 2016年5月1日 (日) 03:07 (UTC)
@Thomas.Lu:查询记录,您就会发现,是Bluedeck当前账户的操作者屡次拿我挂大字报,我只能无奈进行回应,无论是先前在“其他”版还后来在“方针”版(和平已将其移动到其他版),都是如此。我完全无意要和Bluedeck当前账户的操作者进行任何“斗争”,只求他停止永无休止之日人骚扰。上帝啊。Galaxyharrylion留言) 2016年5月1日 (日) 04:17 (UTC)
好啦這串不是要討論您們的衝突,可以回歸正題了嗎...-和平、奮鬥、救地球!留言DC14討論於 2016年5月1日 (日) 04:32 (UTC)
要来回不同分页都会产生不便。因为个人较多使用目录跳到相关讨论,所以问题仍不大,如果能够在每串条目的底部,加入跳回目录的连结。就更为方便。--Thomas.Lu留言) 2016年5月1日 (日) 05:35 (UTC)
  • 左側的工具有“左侧跳顶连接”—John doe 120留言) 2016年5月1日 (日) 06:27 (UTC)
User:Cwek/myTOC.js,浮动目录。——路过围观的Sakamotosan 2016年5月1日 (日) 10:57 (UTC)
印象中以前干过这种事,似乎是和香港有关的一个串,但找不到了。 --达师 - 334 - 554 2016年5月1日 (日) 12:52 (UTC)

(+)支持。翻阅太费劲了。并且不利于存档。--Techyan留言) 2016年5月1日 (日) 14:50 (UTC)

link-en模板手機版去除語言連結[编辑]

{{link-en}}在手機版檢視中,語言有連結,不符合通常不應該被連結的對象第二點。但是我不會去除,其他語言也有相同問題。--tang891228留言) 2016年5月1日 (日) 13:55 (UTC)