RefactoringPolicy

View 1. As often as one sees something incorrect, obviously biased/partisan. It is better to change a page immediately, when one sees something perceived to be a problem, rather than to discuss changes that need to be made. Adherents of this view: LarrySanger

View 2. Only after a discussion has played out. It is better to let the original author of a page to make changes to it. Adherents of this view:

View 3. The middle road -- respect for a dialogue _qua_ dialogue should be respected, but at the same time a minor tweak early on can avoid a flame war. To refactor or not will often depend on the context, and so either rule 1 (change immediately) or rule 2 (wait for the discussion to end) are too extreme. Adherents of this view: JimboWales

Should discussion occur on the page itself or instead on a *Talk or *Discussion page?

View 1. On the page itself. Adherents of this view:

View 2. On a *Talk or *Discussion page, always (or almost always). Adherents of this view: LarrySanger

View 3. The decision to keep the discussion where it is, or move it to a *Discussion page, is contextual. Factors involved in the decision include such things as: how long is the discussion likely to continue, is resolution likely, is the discussion particularly flame-likely, etc. -- JimboWales

What is the purpose of refactoring?

View 1.

View 2.

View 3. I propose that there is a long-run and short-run purpose. The long-run purpose is to turn a discussion into a resource. The short-run purpose is to channel a discussion in a useful direction, i.e. to help aim it at the future time when it can be a resource. --JimboWales

Occasionally a useful middle-ground is to separate the commonly-accepted summary from the discussion. A good way to do this is to place the summary at top, then use two horizontal lines and a word like Discussion: before the discussion. If the discussion grows large or unweildy, it can later be separated into other page(s). --CliffordAdams