跳至內容

維基百科:徵求意見/範例格式

維基百科,自由的百科全書

徵求意見有多種格式,其中部份格式如下所述。所有這些格式皆為可選且有彈性空間

當您選擇討論格式時,請考量您需要何種回應模式,以及最有可能運作順暢的回應。當您想要鼓勵評論或協作時,不要使用「投票」格式。

常規範例

[編輯]

最常規的選擇是採用單一章節,用以包含所有類型的資訊與回應。

這種格式簡單容易適合大多數徵求意見流程,也鼓勵將討論與妥協作為尋求共識的一個手段。如果您要請求的是開放式問題與/或預期會有一般的回應數量時,請強烈考慮此種格式。

==徵求意見:是否要在歷史章節放上相應的照片?==
{{rfc|hist}}
是否應該在「歷史」章節部分包含該船的照片?~~~~

在討論中將投票分開

[編輯]

如果您覺得會有大量回應,請考慮在簡短描述的簽名之後建立一個子章節,例如「意見」,參與者可以在此表態支持或反對;然後再建立第二個章節,如「其他討論」,參與者可以在此進行深度討論。可以要求參與者請勿在意見章節中增加其他回覆,以免導致討論串混亂。

這種格式能鼓勵回應者在不參與討論、分享替代方案或發展妥協方案下進行「投票」。當中最合適的問題就是明確的是/否或支持/反對答案,如「我們是否應該引用這份方針?」,而不是開放式問題,如「這篇條目適合哪一種圖像?」這類格式可以吸引大量的評論,但也可能對該次討論造成殺傷力。

這個結構如下所示:

== 徵求意見:是否要在歷史章節放上相應的照片? ==
{{rfc|hist}}
是否應該在「歷史」章節部分包含該船的照片?~~~~

=== 意見 ===
* {{支持}}放入船的照片,以便讀者閱讀。~~~~
* {{反對}},船的照片和條目內容無關。~~~~

=== 其他討論 ===
* 我覺得有更好的照片可以使用。~~~~
** 請問是那一張照片?~~~~

優點和缺點

[編輯]

對於有「是」與「否」答案的問題,且兩方都有支持的論點時,下列這種並排方式可以使討論串更加平衡。此格式適合用來撰寫有爭議與複雜的中立問題,藉此展示雙方的觀點。

對於有關條目協作的問題,例如有關如何重新撰寫條目重要章節的構想,此格式不如最簡單與常用的格式。本格式僅在針對提案主旨中正反兩方的簡短摘要時才會有效果。如果您需要解釋您所提出原因的細節,或您有其他人不一定同意的理由,請您在表格下方新增,並附上簽名。

== 徵求意見:是否要在歷史章節放上相應的照片? ==
{{rfc|hist}}
是否應該在「歷史」章節部分包含該船的照片?~~~~

{| class="wikitable"
|+ 是否應該在「歷史」章節部分包含該船的照片?
|-
! {{yes}},好主意。
! {{no}},不應該加入。
|-
| scope="col" width="50%" | 這是個好提議,符合維基百科的方針,也確實能改善其內容。
| scope="col" width="50%" | 這個點子在錯誤的時間與錯誤的頁面提出,是個非常糟糕的想法。此外這個提議還沒有任何可供支撐的來源。
|}

這份表格應放在討論章節標題、RfC標籤與問題之後,產生如下內容:

是否應該在「歷史」章節部分包含該船的照片?
是,好主意。 否,不應該加入。
這是個好提議,符合維基百科的方針,也確實能改善其內容。 這個點子在錯誤的時間與錯誤的頁面提出,是個非常糟糕的想法。此外這個提議還沒有任何可供支撐的來源。

任何針對問題的回應,應置於表格下方,如有需要可以增加「===回應===」章節來放置這些回應。

如何處理時間戳記:表格會破壞整個徵求意見列表頁面,因為其管道符號會被辨認為個別的徵求意見列表模板參數。當該表格可能會用在徵求意見的開頭描述時,{{rfc}}模板及時間戳記(~~~~或~~~~~)應當放在表格之前。如果您想要展示誰撰寫了開頭描述,可採用沒有時間戳記的簽名(輸入~~~)。

將支持與反對意見分開

[編輯]

有時候,將參與者支持或反對某些議題的意見分開,是一個好主意。本格式通常只在某項議題有主流的支持與反對觀點,且其他論點或選項的質與量相對不重要時才會使用。這種方法會強迫參與者選擇其中一方,因此只會用於有兩種選擇的議題(如只有支持或反對而沒有中間選項)。除非您預期所提出的議題有大量回覆,否則請避免使用本格式,且實際上您必須要能快速計算(大量的)得票數。

此類徵求意見的格式如下所示:

==徵求意見:我們是否應該重新設計我們的維基專題頁面?==
{{rfc|hist}}
我提議重新設計歷史維基專題的主頁。您支不支持?~~~~

===支持===
# {{支持}}重新設計。~~~~
# {{支持}},只要我們能保留條目統計數據的話。~~~~

===反對===
# {{反對}},不重要。~~~~
# {{反對}}~~~~

===討論===
我對此提案有疑慮。我覺得在同意任何意見以前,必須避免瑣碎的設計。~~~~