Wikibooks:Editing guideline

From Wikibooks, the open-content textbooks collection

This page documents rules and principles for an official Wikibooks guideline that the Wikibooks community has accepted and Wikibookians should follow. Except for minor edits, please make use of the discussion page to propose changes to this guideline.

1 Perfection not required; or, the joy of editing
2 On editing styles
3 Further suggestions for the etiquette and method of editing
4 See further

[edit] Perfection not required; or, the joy of editing

It is a wonderful thing when someone adds a complete, well-written, final draft to Wikibooks. This should always be encouraged.

However, one of the great advantages of the wiki system is that incomplete, poorly-written first drafts of modules can evolve into polished, presentable masterpieces through the process of collaborative editing. This gives our approach an advantage over other ways of producing similar end-products. Hence, the submission of rough drafts (but not too rough) should also be encouraged.

One person can start a module off with an overview or a few random facts. Another person can add a minority opinion. Someone else can round off the module with additional perspectives. Yet another can play up an angle that has been neglected, or reword the earlier opinions to a more neutral point of view. A following person might have facts and figures or a graphic to include.

As all this material is added, anyone can jump in and refactor to turn it into a more cohesive whole. Then more text will be added, then more refactoring, and the module will gradually evolve ever-closer to the ultimate final draft.

During this process, the module might look like a first draft--or worse, a random collection of notes and factoids. Rather than being horrified by this ugliness, we should rejoice in its potential, and have faith that the editing process will turn it into brilliant prose. Of course, we don't have to like it; we even, occasionally, criticize really substandard work, in addition to simply correcting it. The most important thing, though, is to correct it if it can be corrected. For text that is beyond hope, we have gotten into the habit of removing the offending module to the corresponding talk page, or, in cases where the module obviously has no redeeming merit whatsoever, deleting it outright. The latter action should not be taken lightly, however.

[edit] On editing styles

Generally, different people here have different editing "styles". Some people edit lightly, and focus on contributing new content. Others prefer to improve and greatly expand existing "stubs" and modules. Some like to make relatively small copyediting, linking, and page-naming changes. There's room for all of these on Wikibooks.

There are also different editing styles in the sense of how bold people are willing to be. Generally, most of us think we should be bold in updating pages. Virtually no one behaves as though previous authors need to be consulted before making changes; if we thought that, we'd make rather little progress. Quite to the contrary, some of us think you should not beat around the bush at all--simply change a page immediately, when you see something problematic, rather than to discuss changes that need to be made. Discussion, from this point of view, is a last resort. Then there is a more intermediate view, according to which dialogue qua dialogue should be respected, but at the same time a minor tweak early on can avoid a flame war. In this view, to edit radically or not will often depend on the context -- which seems reasonable enough.

Again, there is a place for all of these attitudes on Wikibooks.

With large deletions or replacements, it might be better to suggest changes in a discussion, lest the original author get discouraged and quit posting. One person's improvement is another's desecration, and nobody likes to see their work just flushed without warning.

So, whatever you do, try to preserve information. Reasons for removing bits of an module include:

factual errors
duplication
irrelevancy
patent nonsense
copyright violations

Alternatives include:

rephrasing while keeping the content
moving text within an module or to another module (existing or new)
adding more of what you think is important to make an module more balanced

If, in your considered judgment, a page simply needs to be rewritten or changed substantially, go ahead and do that. But preserve any old contents you think might have some discussion value on the talk page, along with a comment about why you made the change. Even if you delete something that's just plain wrong, odds are that it got there because someone believed it was true, so preserve a comment that it is in fact wrong to inform later editors.

In any event, whether you decide to edit very boldly or to make inquiries on talk page first, please bear in mind that Wikibooks is not a discussion forum. Wikibooks can be a very energetic place, and it's best for the project as a whole if we concentrate our energies on improving modules rather than defending our pet theories, ideologies, religions, etc. Some consideration of Etiquette wouldn't hurt.

[edit] Further suggestions for the etiquette and method of editing

Perhaps export only the parts most likely to be duplicated as an error to the talk, with comments, before altering content. It's easy to do from within the edit window by backspacing, cutting, moving to the talk, pasting with comment. Even easier with two browser windows open, or two tabs. One useful 'safeguard' is to edit in one type browser and browse, check, monitor, extract, compare in the other. For the latter use, one of the Tabbed browsers is best. Firefox and Netscape both fail to search into the edit window, whereas IE6 does, so that is the better browser for copyedits, spelling and minor grammar corrections.

Since the talks can get lengthy with too much, and all content is preserved in history pages, so a paragraph on what is wrong, and a paragraph why is probably the only need 98% of the time. The histories solve the odd 2% where large recoveries are in order. The exception might be when someone attempts a drastic refactoring, but cutting that into a 'temp page' (Sandbox) rather than the talk, with a link to it in the talk (one of those 'organized common resources' mentioned in the below— information is a resource!) page.

Using the top of talk pages as an Organized Project page is a good idea. By that is meant placing project resources, including ToDo lists, lists of who is taking on what sub-part, perhaps an outline, etc. Taking the Heading with a Roster, ToDo's, and some resources as an example, the top section would be a general precise on the aims of that module, followed by the roster which should probably include when someone generally works, Third place resources such as links to other modules, categories (if you use them here) and links to outside references, etc. each to their own sub-section. Fourth, the ToDo list, which people would strike out as items get finished with signature (perhaps use #, and ## items in such— helps in planning and organization, as the numbers can be referred to in talk sections following obviating confusion (of terms or task).

As this list or any talk section gets long, it can be archived to 'clean' the page into the archive page which matches title sections, thus archiving old business and old discussions et. al by archiving just part of a section or many sections is quite easy to do. Such tidiness also helps in keeping the obfuscating clutter away from ongoing business, it's most important feature.

Do retain a conclusion of a long discussion linking to the archived long parts, so others can get involved later or get back up to speed after a time away, as may pertain.

While this 'exercise in verbosity' is not 'On Policy' per se, it goes a long way to keeping collaboration with others amenable and pleasant, so it might be considered as a 'potential guideline' as to how to keep talks fresh enough for everyone to keep up with developments. In this model, the old goes, and the fresh and useful stays that way without fighting clutter.

Last, but not least, some numbering scheme ought to prefix all sections below the fixed sections (i.e. all are categorized as 'temporary topics' even though most of each are eventually separated and archived.) The section ordinal number prefix serves notice when something no longer appears in the ordinal list of sections as it contains only expired discussions, and pertinent information is retained.