维基百科:投票不能代替讨论

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

维基百科上的社群决定源自共识,而共识也就是维基系统的基础。维基百科上透过讨论和辩论解决彼此的矛盾。因此,在维基百科中倾向以讨论而不是正式开立一项投票解决问题。这不是说投票是被禁止的,但应当小心运用,而且应考虑投票以外的其他选择。另外,在少数必须投票的情况下,如果该决定是按“多数裁定原则”所作的,尽可能少用投票解决争议(参看:维基不是民主试验场)。

投票的潜在问题包括:

  1. 可能会因此错过最佳解决方案(或最佳折衷办法),因为这些方案不在投票的选项里。
  2. 由于讨论意见的两极化和引发相关的利害关系,投票可能使应有的文明荡然无存,参与投票的人难以假定善意。就一个具争议性的议题投票,经常会引致上述极其激烈的情况发生。
  3. 投票的人往往预期他们所支持的立场能以多数甚至极大多数自动获胜,然而事实并非如此。
  4. 非正式投票即使已声明没有约束力,有时人们会因此决定在之后追随多数人的意向,也就让之前非正式投票结果变成有约束力。虽然在辩论过程中,请求其他维基人考虑主流意向是合理的,但不应以非正式投票为手段,强迫少数持不同意见的维基人接纳多数人的意见。

在条目的讨论中举行投票[编辑]

在维基百科,我们不会在未经讨论的情况下投票。在讨论某些条目内容上的取舍时,维基人会使用非正式投票来归纳意向。虽然这些投票只是有时出现,有时对讨论有帮助,但这种使用是具争议的。如果要使用非正式投票的话,投票应该协助讨论者最终达成真正的共识,而不是试图压下相反意见。

非正式投票指引[编辑]

删除投票与特色内容投票[编辑]

维基百科有数个程序处理条目删除(WP:AFD)和特色内容(WP:FAC)。这些投票有时被误以为是票数多的一方便会胜出。事实上这些投票并不是绝对地以投票给某一方的人数来作出相关决定,而是当中论据的有效力。所以在这些投票过程中的参与者应该就他们的意见作出解释,也应该检视、考虑其他人的解释。

因为这些过程的主要目的是为了达成共识,所以参与者应该作出讨论而不是简单地投下一票:也就是我们鼓励参与投票的人解释他们的意向,回应其他人意见和可能的折衷方案,而不是单纯签下(+)支持(-)反对,然后不再看一下。试图“控制投票”是没效率的也可能是破坏性的,没有附带理由的“票数”可能对最终的决定没有影响力。

方针与指引[编辑]

维基百科不是民主试验场,方针与指引也不需要通过投票认可。虽然过去曾有维基人争论过方针与指引应经由社群投票或社群的主流意见认可采纳,但是维基的方针明确地驳斥了这些意见。在相关方针下,新的方针与指引可经由以下途径产生:(1)把现行做法整理成方针。(2)经社群共识而成方针。(3) 在某些合适的情况下,由吉米·威尔士维基媒体基金会理事会开发人员的宣布整理为方针。

如上所述,非正式投票也许在极少数情况下能帮助确认各人存在共识,或者可以作为没有约束力的社群意向测试。但由于非正式投票不能创造共识,投票极少能帮助发展方针与指引,反而经常对之产生不良后果。虽然在少量方针获社群接纳时使用过非正式投票和(或)投票,包括WP:3RRWP:SPP和一部分旧有的WP:CSD,但是即使在这些例子里,投票的运用是小心的,而且经过超过一个月的讨论才发起投票。没有指引是通过投票制定的。

许多指引的目的在根本上是要描述现行做法,帮助维基人明白维基百科如何运作。这意味着发起投票或者非正式投票来提议一项方针与指引是不需要的,在某些情况中更是不智的。假若该建议并无争议,便不必“点人数”;如果该建议有争议,“点人数”去看主流意见在那一方不但无助于解决争议,甚至只会激化争议。投票过程本身可能落入争议之中,就投票的技术性细节引发辩论。人们倾向用投反对票,或者开一新段落写上“投票是邪恶的”等方式对这些轻率发起的投票作出回应。

统一标准[编辑]

一旦社群共识决定统一某个项目(例如:模板样式),很可能会有几个不同的建议出现。除非其中一个方案明显得到绝对认同,否则建议进行一次认可投票以选定最佳方案。这有助于将几个都受到支持的可能版本(也常常是相似的版本)归为一个标准版本,是以最终版本便反映了共识。

人物[编辑]

有时我们会在社区的授权投票提名一些值得信任的维基人,尤其是Wikipedia:申请成为管理员。然而,上述所提及的投票结果要经由决定结果的特定人物(例如行政员) 判读。同样地,在这些过程中,建议参与投票者向候选人发问和说明他们的投票理由,而不是简单地投下(+)支持(-)反对而不加意见。

目前有几个讨论是关于Wikipedia:申请成为管理员应该在多少程度上类似多数裁定原则的投票。

功能请求[编辑]

MediaWiki软件的更改由开发人员进行,通常先在Phabricator讨论。有些人很想发起投票请求开发新功能,这样做的是基于一个假设:越多人支持一个功能,开发人员便越会建立这个功能。然而实际情况一般都不是这样,因为开发人员得考虑建议的可行性和系统的负荷能力,这些才是最重要的。

参见[编辑]