維基百科:整理討論

本頁為操作指南，用於介紹中文維基百科社群的一些實作和操作方式。
本文只是論述，不屬於方針或指引。如果本指南與方針或指引起衝突或不一致，請以方針或指引的條文為準。

捷徑

整理討論（重構，英語：Refactoring）是改善討論結構的步驟，頁面內容可能被移動、刪除、修改、重組、隱藏或其他方式，但僅適用於有編者簽署語句（如用戶頁或對話頁）的地方。整理討論有以下作用：

改善頁面的清晰度和可讀性
去除離題、不文明、含糊、或其他分散注意力的材料
重組討論使條理清晰
將材料易位至其他更合適的章節或頁面

比起編修，重構更加簡要概括，但不像存檔那樣能夠反映完整的事實。重構能夠像編修一樣保留作者的原意和目的，但可能像存檔一樣涉及刪除當時曾經存在的文字。重構應當視為一項工具，從「飛快的」討論中分離不需要的雜質，而不等待整個討論正式歸檔。

用語「重構」來自電腦運算的代碼重構，代碼重組（以改善品質）而不改變程式運作。

良好施行重構對維護有成效的討論頁面至關重要。雜亂、仇敵、過於複雜、結構不良、或交叉談論造成擁塞的討論頁面，會使潛在貢獻者喪氣和產生誤會侵蝕了討論的成果。

重構應當僅由討論頁面的參與者基於假定善意執行。若討論頁最近正在激烈地討論，突然進行重構可能缺乏善意。如果其他編者反對，應該還原重構所造成的變化。不過若該頁面超過了建議大小，無需重構仍然可以存檔該討論頁或近期沒有發言的章節。

概述

在過去的維基百科，尤其在2006年以前，討論頁的內容會替換為簡要總結來節省空間──這是一種會丟失原文的重構方法。然而，後來社群開始將討論頁內的討論內容整體存檔，因為存檔可以保存更完整的討論，不會導致其他編者的意見被錯誤表達（無論是純屬意外或故意擾亂），並保留未來可能有用的資料。同樣的原則也開始更廣泛地使用在重構上。

依據規則，編輯者應避免影響其他編輯者所要表達的意義，而不應編輯其他編輯者的留言──這麼做可能會導致陳述被歪曲，會話被打斷，並且影響其他用戶跟進討論。但一些情形下編輯者的發言需要被移除，因為其發言本身擾亂了會話。一般而言，下列情形整理討論是沒有問題的：

非爭議性清理——在任何您能確定其他編者會感謝，而不會感到不快的情況，例如：

補上遺漏的標題和標示
按照維基格式更正段落縮進
修復死鏈
修復例如維基文本格式、表格、模板等技術問題
改進標題，使其具有總結性
修復錯誤的簽名位置（如文本和簽名分離），以及為未簽名的文本掛上{{Unsigned}}
其他的小修改（不建議更正其他用戶的語法錯誤，但是更正明顯的錯字還是可以接受的）

改變討論結構——請注意不能改變討論原意：

根據不同的議題，把文字分成幾個章節
把文字放到更合適的位置
把一段文字移動或複製到不同的章節，針對這一章節發起更集中的討論

刪減會話——只有取得原作者同意，或者依照方針有合理的理由才可以這麼做：

刪除、劃掉、或者隱藏人身攻擊
隱藏多餘的、過時的、或者其他不必要內容
將會話遷移到更適合存放的頁面

如何重構

依據維基百科的討論頁指引，鼓勵編輯者移除任何認定為不適當的內容。只有在移除的會話在其他編輯者的會話中有所提及的情況下，才應該添加指向討論頁歷史的鏈接。關於創建指向會話頁歷史鏈接，參見Help:差異；關於不合宜的會話內容，參見Wikipedia:討論頁指引。

在這裡有數種可用於重構的工具與技術：

刪除: 編輯並將文字完全刪除。Except for non-contentious fixes, this should only be done by the editor who wrote the material or by a sysop or bureaucrat with legitimate cause. Unless a sysop uses Oversight, RevDel, or a page has been deleted entirely, the deleted text will still appear in old revisions of the page.
劃線: 使用HTML的劃線語法─「<s>被劃線文字</s>」會產生「~~被劃線文字~~」。此段文字仍將會在其頁面中讀取，也會顯示在頁面搜尋當中。
Moving text off-page: Material can be userfied or moved to a different page where it is more appropriate. If the refactoring is later reverted, the moved material should be deleted on the pages it was moved to prevent proliferation of the text.
Hidden divs, collapsible tables, and templates: A number of tools and templates hide or block text from further editing – {{hidden}}, {{cot}}, {{hat}}, {{archive top}}, {{discussion top}}. These work by creating collapsible tables or hidden divs. Material collapsed in this fashion does not show up in page searches unless it is in an expanded state.

The tool or technique used should be chosen according to the particular needs of the material.

The creation of an FAQ is recommended for any points that are likely to be repeatedly raised and refactored. Existing material should be generalized appropriately and reformatted into a simple question/answer format so that later editors can have their concerns satisfied without raising the question again. Likewise, lengthy ongoing discussions might benefit from template refactoring with a summary. The {{quote box}} template can be used to provide a floating summary box next to a refactored discussion, or a comment may be added at the bottom (or sometimes the top) of a section.

截除

In some cases, discussion should be broken down into new sections or subsections. This is useful when a section becomes overly long, or when conversation begins to diverge into a number of separate points. Resectioning may help both readers and participants understand the flow of the discussion and help them find relevant parts of the text.

For long discussions, participants often insert arbitrary breaks by adding a new subsection heading. In fact, such breaks are often given headings like 'Arbitrary break' or 'convenience break', with an index number to distinguish it from other arbitrary break headings. Discussions that cover multiple points or become more complex, by contrast, may benefit from the creation of subsections to address different points, or in extreme cases by splitting off sections of text into entirely new sections. It may be necessary in these cases to reorganize large swatches of text, and if so care should be taken to ensure that no comments are taken out of context or lose connection with the original point they were addressing. It may be advisable to copy sections of text rather than move them (adding a comment that refers back to the original text), to duplicate the original author's signature across different points that have been moved to different sections, or to begin the new section with a parenthetical statement explaining the original context of the comment.

請參考下面的範例。

考量

在進行重構時，應注意以下考量：

Refactoring may cause confusion if improperly applied to an ongoing discussion; an editor should take great care to preserve all such discussion and all relevant details to its context.
Editors should be conscious of the newcomer's perspective; one should not remove content that would benefit an editor who had not yet read the page.

Be aware that not every editor will agree with your refactoring or even of the refactoring concept in general. Provide links to the original, uncut version, so others can check your changes, and if necessary go back to the original to clarify what an author actually said. This combination of refactoring and archiving will often prevent complaints that information was lost. Make it explicit that you have refactored something so no one is misled into thinking this was the original talk page.

If you think people may object to their discussion being refactored, make your summary on a different page. Rather than reducing archives 7 to 10 of Talk:New Imperialism, create a new page entitled [[Talk:New Imperialism/Summary of archives 7 to 10]]. Link this to the top of the appropriate archives, and to the current talk page. This gives newcomers the chance to get a quick understanding without the risk of losing what has gone before. Having a linked archive can help satisfy both those who feel their words must remain intact and those who want a neat summary.

進階工具

Simple refactoring can easily be done with standard Wikipedia browser editing, but if you are faced with a particularly complex or tedious refactoring job, an advanced text editor or any of an assortment of scripting languages can be immensely helpful. Basically, any tool that has extended find and replace features, regular expression capabilities, or programmatic text processing will become your best friend. Alphabetizing material, sorting sections into chronological order, changing multiple links, restructuring large tables – these tasks can be painful and time consuming to do by hand, but can be accomplished in a matter of minutes programmatically. Most high-end 'Office'-type have advanced text editing capabilities, and many light-weight but powerful text editing applications are available – see list of text editors. Many scripting languages for text processing also exist; common ones are Perl, Python, Unix shell scripting, and AppleScript.

For long refactoring jobs, it may help to tag the page(s) being refactored with Template:Refactoring. Simply add {{refactoring}} to the top of the page(s). This will alert other editors to the fact that the pages are under construction, and should help minimize edit conflicts.

明顯範例

Talk pages or talk page sections that have benefited from refactoring:

Mother Teresa
Exterior to what? Ausdehnungslehre means "extension theory", not "exterior theory" (conservative refactoring by inserting paragraph titles)
Is there a convention about the order of multivector components? (conservative refactoring by inserting subheadings and paragraph titles)

參見

外部連結