Wikipedia:Refactoring talk pages
From Free net encyclopedia
{{{1{{{1|}}}|
Refactoring of talk pages on Wikipedia is important. New editors to a page need to be aware of past controversies without having to read 50,000 words beforehand, which for some pages (Talk:Mother Teresa, for example) is how much of the talk archives have accumulated.
You should be aiming to increase the signal-to-noise ratio, have less redundancy and less information overload. Think what the talk page is about and remove anything superfluous that would not help future editors to the page. Do not discard useful information; if something is important but irrelevant, move it somewhere more appropriate. A good place to start can be your own comments. If you've asked a question on the Village Pump or Help Desk, and it has been answered, try summarising the outcome.
Contents |
When to refactor
Consider these guidelines when refactoring a discussion:
- Refactoring may cause confusion if improperly applied to an ongoing discussion; however, proper application should enhance the clarity of the discussion and therefore lessen the risk of confusion.
- Refactoring must be done responsibly and objectively. The original meaning of the refactored statements pertinent to the subject of discussion must not be obscured.
Refactoring may occur more than once. Constant refactoring is a good thing and you can refactor as you go.
Benefits of refactoring
- "Refactoring is a process of discovery for all involved -- refactorer included -- so even though it's careful work, it can also be tremendously instructional." [1]
Whilst you risk adding bias to summaries of pages in which you are involved, it can be an excellent way of catching up with the discussion and getting it clear in your own mind exactly what went on. There may have been valid points that you missed in the heat of the discussion, which when you come to refactor, you are more likely to notice. With pages such as the village pump, refactoring can be a great way of learning as you need an understanding of something to make a sensible summary.
Dealing with signatures
Remove signatures if you change someone's comments. Don't make it look like they wrote the changed words. If a comment needs a name attached, turn it into a third person statement. "Jimbo said Wikipedia's great" rather than "Wikipedia's great --Jimbo".
Sometimes leaving the original wording may be best for some sections. If you do this, make it clear which parts have and have not been refactored.
The noise on a page can be reduced with the following example, but please note that editing or deleting signed comments can be controversial.
Before
- Dogstar3000 is a troll and needs to be banned! Newbie
- Please take it to WP:RFA. This is not what the village pump is for. UserA
- WP:RFA is requests for adminship. Maybe you meant Wikipedia:Requests for arbitration? UserB
- Oops, yeah sorry about that. I did mean Requests for arbitration obviously. UserA
- WP:RFA is requests for adminship. Maybe you meant Wikipedia:Requests for arbitration? UserB
- Please take it to WP:RFA. This is not what the village pump is for. UserA
After
- Dogstar3000 is a troll and needs to be banned! Newbie
- Please take it to Wikipedia:Requests for arbitration. This is not what the village pump is for. UserA
Similarly, if you make a comment which in hindsight was pointless, you could just delete it rather than justify it.
- I think the listings on votes for deletion should all be left a day longer to account for the server downtime. UserA
- UserC has already done this. UserB
- Ok, I didn't notice. I guess I should have looked at the page first but it was really slow to load and I couldn't be bothered. :/ UserA
- UserC has already done this. UserB
As his original comment had no value, UserA could have simply deleted it rather than responding to it. This saves other users with the page on their watchlist reading through the irrelevant conversation. See also Wiki:DeleteDontJustify.
Dealing with objections
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.
Methods of refactoring
Summarise
If a talk page is too long, you can summarise it. However, refactoring is often more than just summarisation, as it may involve reorganising the text as well as shortening it.
Remove off-topic comments
When refactoring a talk page, remember that Wikipedia is not a chat room. People may have chatted while developing an article, but is this going to help future editors working on the page? Probably not, so condense it to what is relevant to the article, bringing out the points of argument, while leaving behind the personal attacks and off topic comments about who should be banned, and who violated their sysop privileges while editing the page.
If a comment has some value, reorganise it or move it. If not, delete it. The full archive is there for those with the time and inclination to read it. Your summary should be of maximum benefit to the most readers.
See also: Wikipedia:Taking it outside (WP:TIO)
Replace question and answer
One easy way to refactor is to turn a question and answer into a statement.
Example: Before:
- ==A question from a newbie...==
- How can I increase the font size on Wikipedia? NewbieUser
- Go to User: NewbieUser/monobook.css and add font size:160%. RandomUser
- Thanks RandomUser. That worked! NewbieUser
After:
- ==Changing your font==
- To change your font size, add font size:160% to [[User:<yourname>/monobook.css]].
With this example, the useful information is kept. It also shows why you shouldn't refactor too soon, as RandomUser might not have seen the thanks by NewbieUser. Sometimes, it may be important to note the authorship of a question, particularly if the answer may be seen as controversial by some, so you could write:
- To change your font size, RandomUser suggests adding font size:18pt to [[User:<yourname>/monobook.css]]. However, RandomDeveloper says you should use 160% instead of 18pt to avoid absolute font sizes.
If there is not clear agreement on the right answer, give both, and assign names to them to help people decide which answer they believe. This can be very useful on large pages such as the village pump if you don't want to archive the whole page or it is too early to move a section elsewhere.
Replace discussion with FAQ
If the same topic of discussion keeps coming up, consider making a FAQ. Just convert the existing question and answer sessions into a more polished document. This may not only reduce the existing duplication on a talk page, but also prevent future duplication. See talk:Mother Teresa/FAQ for an example.
Reorder and rename
Refactoring a page does not have to be as complex as rewriting it. A page can be more readable simply by grouping related topics together. Most talk pages will be chronological. You don't need to keep this structure. Perhaps a page would be clearer if split into a list of for and against arguments.
If a talk page has a number of archives, it may be helpful to move these to more appropriately named pages. For example, Wikipedia talk:requests for adminship/should bureaucrats use their judgement is far more valuable than Wikipedia talk:Requests for adminship/Archive 17. Collect up all the related threads on bureaucrat judgement and put them in a named archive. You may want to leave links from the original archives to show where the discussion has moved. If a topic is frequently recurring, make a new talk page for it. For example, have Wikipedia talk:Manual of Style (dashes) rather than having the monthly debate on the value of emdashes spread across a dozen different archives. This makes it far easier for people to catch up on the past discussion and saves them having to wade through other Manual of Style discussions on whether God should have a capital G when they only want to know about emdashes.
If you split a talk page into separate archives then split by topic, not by opinion. This prevents people focusing only on the page that supports their opinion (or on the one that doesn't when they're looking for a flame war). It also prevents having the neutral opinions lost.
Reordering is particularly useful following what MeatballWiki calls a Forest Fire. This is where an argument has exploded over many pages, typically high activity areas such as AfD, vandalism in progress, the village pump, requests for page protection and so on. It could also be over a series of related article talk pages. This makes it hard for outsiders to follow the argument, and makes the talk pages far less useful in the long term. The solution is simply to collect up all the related discussion and put it on one page, leaving links from the other pages.
Add an overview
Ongoing discussions that are not yet ready to condense might benefit from a summary. This can be added to the top for people who need a quick overview but don't want to get involved with the heated discussions. It might also help those having the argument to stay on focus.
Other methods
If you don't have time to refactor a page, you can still make it more useful simply by adding more informative subheaders. For example, "Changing your font" will be a far more useful header for a reader than "A question from a newbie…" would be. Going through a page and adding links to related talk pages can also be useful for future readers. If it is a talk page you were involved in, you may want to go back over it later and clarify points that would not be meaningful to other users. Add in things that you and the person you were talking with were taking for granted, that might otherwise be forgotten in a few months time. For example, if you choose to completely ignore comments from a particular user, will it be obvious to future editors that this user was a troll who was soon after banned? The aim is to make the talk pages useful beyond the initial conversation. Think of ways to encourage future editors to read them.
Tools
When refactoring, it is often very helpful to have an advanced text editor with extended find and replace functionalities. Also, if you're technically inclined, scripting languages are immensely helpful in situations involving complex-but-regular text manipulation. For example, sorting a number of sections into chronological order is a painful task to do by hand, but if you're handy with scripting languages, you can save a lot of time and effort. Good scripting languages for text processing include Perl, Python, and Unix shell scripting.
On the wiki side, it helps to tag the page(s) being refactored with Template:Reorganizing. Simply add {{reorganizing}} or {{refactoring}} to the top of the page(s). This will alert other editors to the fact that the pages are under construction, preventing edit conflicts.
See MediaZilla:1843, a request for an archiving feature in MediaWiki.