text:
Technical writing/Style

Back to Technical Writing Level 1

Wikiversity Main Page

Contributor: Susan Flander

Technical Writing Videos
Williams Technical Writing Videos

Free short videos are available from TWFred (an author of Wikiversity's Technical Writing Course) explaining technical writing strategies and techniques. These videos complement the contents of this Wikiversity course. Topics include the following:

 * Using Active Voice
 * Structuring Descriptions, Steps, and Outcomes
 * Avoiding Ambiguity and Exaggeration
 * Choosing Terminology
 * Writing for User Personas

Goals

 * Inform (educate) the user.

 * Write clearly, using words the audience understands.

 * Compose simple, active voice sentences.

 * Understand the audience and speak directly to the reader.

 * Use active voice, appropriate grammatical person, present tense, and the imperative mood.

 * Determine if the text requires a change in grammatical person or past tense, future tense, and/or declarative mood.

 * Avoid unnecessary repetition, redundant jargon, and passive voice.
 * Evaluate your writing: write, review, and repeat.

Important information first
Important information at the beginning of a sentence makes it easier to understand.

Example

Unclear:

 * The unwise walking about upon the area near the cliff edge may result in a dangerous fall and therefore it is recommended that one remains a safe distance to maintain personal safety.

Clear:

 * Danger! Stay away from cliff.

Use your audience's vocabulary
Good technical writing improves the reading experience. Use synonyms for "technical" terms to make the reader's document search more effective.

Source: by Barry Millman, Ph.D.

Understand your environment
Some business environments don't understand the technical writing style, insisting on passive voice and artificial formality. Modern technical writing directly addresses the reader in an unpretentious way.

Sentence structure
Good sentence structure helps convey information. Try to keep the most important information towards the beginning of the sentence.
 * No
 * Furthermore, large volumes of water are also required for the process of extraction.

 * Yes
 * Extraction also requires large volumes of water.

Long sentences
Long sentences tax the brain and make remembering information difficult. Strive to keep sentences under 16 words. Split long sentences into two or more chunks. A sentence that lists three or more items may work better as a bulleted list.

Short sentences
The most basic sentence is a simple sentence with only one clause. Evaluate each sentence to ensure it contains sufficient information.

Quotation marks
In the U.S., periods and commas usually fall inside the quotation marks. In the UK and most other countries, terminal punctuation usually goes outside the quotation marks unless part of the quotation. This style (sometimes called logical punctuation) is also permitted in American writing where precision is necessary, e.g. in presenting computer code and commands, or in textual criticism.

Avoid the obvious
Understand the audience's technical level. Know what terms they understand and what terms you must define.

Avoid padding
When reading a piece of technical writing, the audience does not benefit from elaborate prose. They just need information on how to perform a task. Avoid using padding, or filler. Don't use phrases such as, kind of, sort of, and essentially.

Avoid redundant prepositional phrases
Prepositional phrases, the combination of a preposition with a noun phrase, are among the worst offenders in making text long and tiresome to read. Often, it is possible to replace an entire phrase with a single word.
 * Use now instead of at this point in time.
 * Use suddenly instead of all of a sudden.

Avoid verbosity
Write short, succinct sentences. Never say, "...as has been said before," "..each and every," "...point in time," etc. Avoid "...in order to," especially at the beginning of sentences. Every word must contribute meaning to the sentence. Technical writing is information delivery.

Avoid pomposity
While it is good to have a wide vocabulary, technical writing is not the place for showing off linguistic abilities. Technical writing is about producing clear, plain instructions for a specific audience.

Write clearly
George Orwell's general writing rules work for technical writing:

 * 1) Never use a metaphor, simile, or other figure of speech you are used to seeing in print.
 * 2) Never use a long word where a short one works.
 * 3) If it is possible to cut a word out, do so.
 * 4) Never use the passive voice. Use active instead.
 * 5) Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.

Exceptions for technical writing

 * 1) If the audience habitually uses a particular metaphor, simile, or other figure of speech, you can use it too.
 * 2) If scientific jargon is a standard, ensure you follow it.
 * 3) Once you explain a word or term, you have made it usable in that document as a technical term—so use it consistently for that element.

Look at the Basic English ordered word list.

Use active voice
Active voice clearly shows the actor in a situation. When we read active voice, we know who does what to whom. Active voice is shorter and more interesting to read. Active voice is the standard for technical writing.

 * Active
 * A. They speak English.

 * Passive
 * B. English was spoken.

Passive voice obscures the actor—sometimes deliberately, as in, "Mistakes were made." Passive voice is ambiguous and often leaves out important information. Who made those mistakes?

 * Active
 * The administrator edits the file.
 * The administrator edits the file.

You can identify the passive voice easily. Sentences that have the word "by" are almost always passive. Past-participle verbs—"was eaten," "is driven"—are usually passive. You can always rework a passive sentence to turn it active. Often, you just put the actor first.

 * Passive
 * The file is edited by the administrator.

 * Active
 * Various authors wrote this Wiki.
 * I made a mistake.
 * Chew the burrito well.
 * Chew the burrito well.

 * Passive
 * This Wiki has been written by various authors.
 * Mistakes were made.
 * One must masticate thoroughly to ensure the burrito will have been eaten completely.

Common intransitive verbs
The following verbs cannot be used in passive voice: appear, arrive, come, cry, die, go, happen, occur, rain, sleep, stay, walk.

Understanding present tense
Computers have no past, and no future. Everything happens in the present as a direct result of some event, usually caused by the user. As each event takes place, the computer has a reaction. Each of these events happen in the present, so good technical writing uses the present tense almost exclusively.

Grammatical person
First, second, and third person refer to personal pronouns that reflect a point of view in singular and plural forms. Each "grammatical person" can be written in subjective case, objective case, or possessive case.

When writing or editing technical content, consider the sentence or paragraph's meaning. The two examples below demonstrate common uses of third and second person.

Example: Third person - active voice

 * The Options menu item specifies which model components display. Selecting Options produces a pop-up dialog box with toggle switches grouped into Elements, Rendering, and Reference Geometry.

Second person
The second person point of view addresses a reader or listener directly. Second person addresses the reader, the person your writing speaks to ("you" for both singular and plural).

Here is an example of the imperative mood with the pronoun your:

 * Turn in your cycle log each Friday.

Contractions
Plain language specifications generally specify that you use contractions where appropriate. Do not use irregular contractions, or contractions that reflect future tense or passive voice—e.g., "...the motor'll start."

Shorten sentences
Readers process and understand short, active voice sentences. Remember that instructions you provide the user must indicate: who, what, where, and how to perform the action. Workers should tighten the chuck with great care because incorrect tightening may result in damage to the drill bit. Tighten the chuck carefully to avoid damaging the drill bit.
 * No
 * Yes

Avoid ambiguous sentences
Do not write sentences that the reader may interpret in more than one way.
 * No
 * The user may choose to open the chosen file, and it will automatically open itself when it is hit by the mouse.

 * Yes
 * Click any file to open it.

Write for application consistency
Commonly, steps in a procedure or task follow the navigational structure of the application left to right, top-down. Each step must include the menu commands, or dialog box and field names in the sentence. The top-down method determines the "big picture" (global view) of the application first and then defines its features in detail. Note, based on the language we may read right to left.
 * No
 * Select Rename from the Edit menu.

 * Yes
 * On the Edit menu, select Rename.

Action verbs, menus, and commands
We interact with computers in a variety of ways. You can select anything on an application user interface by selecting it using a keyboard or mouse. It is important to use action verbs and software terminology correctly.

The most frequent verbs used in software are:

 * Click
 * Double-click
 * Select
 * Type
 * Press

Use of an action verb in a sentence (bolded words):

 * 1. In the dialog box, click Open.

 * 2. Type a name in the text box.

 * 3. On the keyboard press Enter.

Use of menu actions and commands in a sentence:

 * 1. On the File menu, click Open.

 * 2. Type a name in the User Name field.

 * 3. In the Open dialog box, click Save.

 * 4. On the computer keyboard, press Enter.

Make users aware of where they are in the application. If there is more than one method to perform an action, use the most common method. Define "what, where, and how" in each step of the task or procedure. Describe menu items for the current task left to right, top-down.

Example:

 * On the File menu, click Open File.

 * Or
 * On the toolbar, click the Open File icon.

Specifying gender
English provides no dedicated pronoun for the gender-neutral third-person singular. The word "it" refers to animals or inanimate objects. Writers often use the gender-ambiguous plural pronouns: "they," them," and "their," to describe individuals of unknown gender.

 * Example (using male singular)
 * I saw someone in the distance. I could not see if he was male or female, but his coat was definitely brown.

 * Example (using gender-neutral)
 * I saw someone in the distance. I could not see if they were male or female, but their coat was definitely brown.

In technical writing, the gender-neutral pronouns, they, them, or their, are preferable to the verbose he or she/his or her/him or her. If a sentence seems awkward, try to avoid the issue: leave out the pronoun or use second person imperative. These examples assume the operator is the audience:

The operator must turn in his or her cycle log each Friday. The operator must turn in their cycle log each Friday. Turn in your cycle log each Friday.
 * Bad
 * Better
 * Better still

Writing for translation: Use gender-specific pronouns when writing for a language that uses personal pronouns that differ according to gender.

How long can a list be?
Most people can associate between five and nine data items together. Therefore, keep your lists short. If any list of instructions has more than seven steps, try to break it into two or more groups, with an intermediate state between. Again, there is no iron rule. Do what is reasonable in your circumstance.

Lists are a useful tool in technical writing, as they break-up overly long sentences into information chunks that are easier to digest than long-winded monologues.

Why use lists?
Lists are useful because they:
 * Break up long sentences
 * Create easy to digest information chunks

Ordered and unordered lists
Use unordered (bulleted) lists when the audience doesn't require that the information be in any particular order, as in lists of:
 * Features
 * Options
 * Components

Note: Options are non-exclusive possible actions in the software.

Use ordered (numbered) lists when the audience needs the information in a particular order, or needs to refer to list items by number:

 * 1) Steps of a procedure
 * 2) Items on a check list
 * 3) Requirements in a specification

Even lists can become overly long and require breaking up, this is best achieved by separating the information chunks as described in Technical writing structure into chunks. Most people can remember a maximum of 7 ± 2 items without too much hassle, as proposed by George Miller. Generally, however—once a list goes above 10 items, sub-divide it.

Example

Shopping List

 * Yogurt
 * Bread
 * Tea
 * Milk
 * Biscuits
 * Crisps
 * Pork chops
 * Chicken
 * Cheddar
 * Chocolate

 * Dairy
 * Yogurt
 * Cheddar
 * Milk
 * Meat
 * Chicken
 * Pork Chops
 * Snacks
 * Chocolate
 * Biscuits
 * Crisps
 * Drinks
 * Tea

Punctuation
Just as in regular text, it is important to punctuate lists correctly. If the list is made up of phrases, capitalize the first word of each list item. Do not end each list item with a comma or full-stop (period).

Example

The new Skoda Fabia has the following benefits:

 * Greater fuel efficiency
 * Expanded head room
 * Expanded rear leg room

When items are complete sentences, begin with a capital and end with a period.

Example

The new Skoda Fabia has the following benefits:

 * The fuel efficiency is greater.
 * There is more head room.
 * There is increased rear leg room.

List items are sometimes an initial phrase followed by a complete sentence. In that case, use capital letters and full stops (periods) for the phrases as well as the complete sentences.

Subject
Subject matter is important. Remember that warnings come first. Apply warnings to any documentation that includes a task or procedure that causes damage to life or property.

Formality
Part of our task as information specialists is to write in a tone suitable for the audience. In writing for educated and experienced engineers, an informal tone is inappropriate. Most technical writing requires a reasonably formal style. When deciding on style and tone, audience, subject, and purpose are the main considerations.

Audience
Audience awareness dictates style. As we are writing for professionals we must write professionally, in a reasonably formal style.

Purpose
Our purpose is to inform, not to entertain. So our writing must be informational.

Clarity
Seven guidelines for clear writing.

 * Use active voice

Active voice works better than passive in technical writing because it focuses sentences on the person or other entity that performs the action—the agent, or actor. For clarity, active voice is vastly preferable to passive, though occasional situations make passive voice unavoidable.

 * Be specific

Use precise words as opposed to more general variants. Provide enough detail to inform the reader. Avoid ambiguity. Many words in English have multiple meanings; make it clear which meaning you intend.

 * Eliminate useless jargon

"Jargon" is a field's specialist vocabulary. Computer scientists speak of a "network" and mean something different from when a sociologist talks about a "network." Jargon is a necessary part of modern life, but we must be aware of what jargon the reader knows and how they use it.

 * Be positive

Avoid phrases that contain negative elements like "no" or "not." For example, "impossible" is a positive construction as opposed to "not possible." The main reason for using positive constructions is that the reader more readily understands information in this form.

 * Avoid long noun constructions

English commonly uses a noun as an adjective, which can cause unwieldy phrases. Often, you can clarify this with a hyphen between, for example, two nouns used as adjectives (as in the phrase "flat-bed plotter"). Clarity demands that we must write to make the meaning clear.

 * Don't use cliches

Cliches are outdated ways of writing that often represent a writer's attempt to impress. Good writing is original and clear. The best English is plain English.

 * Don't use euphemisms

Say exactly what it is you want to say, don't avoid writing the uncomfortable.

Simple English
When writing for audiences that include non-native English speakers, it is important to write simple, straightforward sentences and avoid colloquialisms. Some industries have adopted a “Simplified English” that consists of about 1000 words, each with a single meaning. Be aware of any relevant simplified English for the target industry, so you can write text that the audience can understand.

Articles
Articles in English present some of the most difficult aspects of grammar. Here are the rules.

The
Articles in English are invariable. They have one form regardless of the subject: "the" is always "the," and refers to:
 * Something already mentioned: An MGC is a "Media Gateway Controller"; the MGC controls all activity on an IP phone network.
 * Something both speaker and listener understand, even if not previously mentioned: "Where is the kitchen?"
 * A particular person or object: The person who wrote the documentation has excellent style...
 * Unique objects: the sun, the moon, the world...
 * Superlatives and ordinal numbers: The best, the first...
 * With adjectives, to refer to a whole group of people: the Japanese, the old...
 * Geographical areas and oceans: the Atlantic, the Gobi Desert...
 * Decades, or groups of years: the Seventies, the early 19th century...

A/an
Use 'an' with nouns that start with a vowel sound (a,e,i,o,u) and 'a' with nouns that start with a consonant sound (letters that are not vowels):
 * A chair
 * An apple
 * A truck
 * An orange
 * A castle
 * An opera
 * A historical (an historical is archaic and incorrect at least in the U.S.)
 * A Media Gateway Controller
 * An MGC (M is pronounced em, so it is a vowel sound)

Note: Silent H words

 * Use 'an' before a silent h:
 * An hour

Note: U or Eu words that make a Y / "You" sound

 * Use 'a' before words like:
 * A European
 * A university
 * A unit

The Indefinite Article is used...
to refer to something for the first time:

An MGC is a "Media Gateway Controller." The MGC controls all activity on an IP phone network.

with jobs: with nationalities and religions: with names of days: to refer to a kind of, or example of something:
 * John is a builder.
 * Sarah is training to be a doctor
 * He hopes to be a footballer.
 * Dick is an American.
 * Panjet is a Sikh.
 * I was born on a Thursday.
 * The server room is a noisy place.

with singular nouns, after the words 'what' and 'such':
 * What a shame!
 * She's such a beautiful girl.

to mean 'one', referring to a single object or person:
 * I'd like a pay raise please.
 * The writer wrote a novel.

Notice also that we usually say a hundred, a thousand, a million.

No Article is used...
with names of countries (if singular):
 * Germany is an important economic power.
 * He's just returned from Zimbabwe.
 * (But: I'm visiting The United States of America next week.)

with the names of languages:
 * French is spoken in Tahiti.
 * English uses many words of Latin origin.
 * Indonesian is a relatively new language.

with the names of meals:
 * Lunch is at midday.
 * Dinner is in the evening.
 * Breakfast is the first meal of the day.

with people's names (if singular):
 * John's coming to the party.
 * George King is my uncle.
 * (But: we're having lunch with the Morgans tomorrow.)

with titles and names:
 * Prince Charles is Queen Elizabeth's son.
 * President Kennedy was assassinated in Dallas.
 * Dr. Watson was Sherlock Holmes' friend.
 * (But: the Queen of England, the Pope.)

After the 's possessive case:
 * His brother's car.
 * Peter's house.

with professions:
 * Engineering is a useful career.
 * He'll probably go into medicine.

with names of shops:
 * I'll get the card at Smith's.
 * Can you go to Boots for me?

with years:
 * 1948 was a wonderful year.
 * Do you remember 1995?

With uncountable nouns:
 * Rice is the main food in Asia.
 * Milk is often added to tea in England.
 * War is destructive.

with the names of individual mountains, lakes and islands:
 * Mount McKinley is the highest mountain in Alaska.
 * She lives near Lake Windermere.
 * Have you visited Long Island?

with most names of towns, streets, stations and airports:
 * Victoria Station is in the centre of London.
 * Can you direct me to Bond Street?
 * She lives in Florence.
 * They're flying from Heathrow.

in some fixed expressions, for example:
 * by car
 * by train
 * by air
 * on foot
 * on holiday
 * on air (in broadcasting)
 * at school
 * at work
 * at University
 * in church
 * in prison
 * in bed

British or American English?
There are minor differences in American and British English. For example:
 * Spelling differences—color vs. colour; realize vs. realise
 * Americans put periods and commas inside quotes, British outside—The sign said, "push." vs. The sign said "push".
 * In the US, ground floor and first floor both mean the floor at street level; in Britain, the first floor is the floor above the ground floor—which Americans call the second floor.

Screen terminology
Use consistent terminology when you refer to the user interface: The Microsoft Manual of Style for Technical Publications, 3rd ed. provides good recommendations for graphical user interface (GUI) terms.
 * Area
 * Button
 * Check box
 * Close button
 * Desktop
 * Dialogue box
 * Dropdown lists
 * Expansion boxes
 * Fields
 * Filenames
 * Folders
 * Icon
 * Keyboard keys
 * Maximize button
 * Menu and menu item
 * Menu bar
 * Minimize button
 * Non-GUI screen
 * Option button
 * Paths
 * Quick Launch bar
 * Scroll arrow
 * Scroll bar
 * Scroll box
 * Start button
 * Submenu
 * Tab
 * Taskbar
 * Taskbar button
 * Title bar
 * URL address
 * Window
 * Wizard page

Names for keyboard keys
Spell keyboard key names as they appear on the keyboard in both text and procedures. Use all capital letters referring to specific keys. Write arrow keys in small letters when referring to them generally. When writing about a specific arrow, for example \’DOWN ARROW\’, use all capital letters.
 * ALT
 * ALT GR
 * arrow keys
 * BACKSPACE
 * BREAK
 * CAPS LOCK
 * CLEAR
 * CTRL
 * DELETE
 * DOWN ARROW (use with the and key)
 * END
 * ENTER
 * ESC
 * F1-F12
 * HOME
 * INSERT
 * LEFT ARROW (use with the and key)
 * NUM LOCK
 * PAGE DOWN
 * PAGE UP
 * PAUSE
 * PRINT SCREEN
 * RESET
 * RIGHT ARROW (use with the and key)
 * SCROLL LOCK
 * SELECT
 * SHIFT
 * SPACE BAR (use with the)
 * SYS RQ
 * TAB
 * UP ARROW (use with the and key)

For information on keyboard key names not mentioned here, see Microsoft Manual of Style for Technical Publications, 3rd ed.

Dictionaries, thesauruses and grammar checkers
A part of the skill of writing is the use of dictionaries, thesauruses, and grammar checkers. For best results, use them often and in the formal writing setting. This alleviates words in passive voice, repetitive usage, and spelling errors.

Style manuals
A style manual helps writers adhere to evolved rules and conventions. In the U.S., writers use style guides from academic institutions, professional organizations, and corporations. The major style guides, however, are the Associated Press Stylebook and the Chicago Manual of Style (CMS). Generally speaking, journalists use the AP Stylebook and most other writers CMS, unless their work requires the style guide of a particular institution or corporation. The Microsoft Manual of style began as Microsoft's corporate style guide but enjoys wide use by technical writers for computer-specific issues.

Why use a style manual?
A good style manual guides writers through the complex world of English punctuation, syntax, grammar, and other writing issues. In some cases, style manuals disagree on minor points. For example, journalists, who follow the AP Stylebook, do not usually use a terminal comma: "chickens, ducks and geese." Outside journalism, writers who follow CMS use a terminal comma: "chickens, ducks, and geese." Use the convention appropriate for the type of writing, but even more importantly, use the same convention all the way through the document or project. A style manual provides a basis for applying rules and conventions consistently.

 * The Chicago Manual of Style
 * The Chicago Manual of Style (abbreviated in writing as CMS or CMOS, or verbally as Chicago) is a style guide for American English published since 1906 by the University of Chicago Press. In the United States, it is the most widely used style guide for non-journalistic content.

 * Microsoft Manual of Style
 * The Microsoft Manual of Style for Technical Publication (MSTP) is widely used in the technical environment. The first edition was published in 1995.

 * Associated Press Stylebook
 * The Associated Press Stylebook and Briefing on Media Law, usually called the AP Stylebook, is a style and usage guide used by newspapers and the news industry in the United States. It is not widely used outside of journalism.

title: Technical writing/Style


text:
Technical writing/Edits

back to Technical Writing Level 1

Ego and the technical writer
Technical writing relies on delivering accurate and precise information. Commonly, management and designated subject matter experts review all work performed prior to a documentation release. It is important to understand that a documentation review is not personal; diction and style is always a point of critique.

The famous English actor and scriptwriter Michael Knowles once said:

 "Leave your ego at the door. Big egos cause big problems. Give me one good, persistent writer with a small ego and the two of us will do the work of ten"

Planning

 * Define — exactly what are we writing? At this point we must decide on the format of our work.
 * Scope — at this point we decide the parameters within which we will prepare our writing, always being mindful of the persona.
 * Developing the plan — a detailed break down of how the writing plan will be executed.
 * Monitoring — setting procedures to keep the work flow on track.

Analysis

 * Persona needs — How will the text meet the needs of their persona? We cannot answer this question without being aware of those needs.

Design

 * Blueprint - we now create the actual structure of the document we are preparing, how it works.
 * Interface - how will the document look?

Develop
Once the work has been fully planned we now instigate the following steps:

 * Research - find the information to be presented in the document.
 * Writing - create the text that will form the body of the work.

Test

 * Scope of the tests - what is to be tested and how?
 * Pass/Fail criteria
 * Test schedule - when are the tests due to take place and how long will they last?
 * Validate - test the refined text before moving on to the next stage
 * Refine - make any necessary amendments and improvements to the text or the structure, to meet more closely the needs of the persona

Test Cases
When a test is formally written up, this is known as a test case and has three parts.

Information
This section contains general information about the test, such as:

 * Identifier - each test case has a unique number or code for ease of tracking
 * Tester - the person who created the test
 * Name - a test should have a human-friendly title for easy recollection
 * Purpose - a brief description of what the test expects to do

Activity
This describes the actual test in the following terms:

 * Environment — the conditions under which the test took place
 * Initialisation — tasks undertaken before the test begins
 * Finalisation — tasks undertaken once the test is completed
 * Actions — a step-by-step guide to the test

Results

 * Expected results - what should happen
 * Actual results - what really happened

Test Tracking
Testing needs to ensure that the document fulfills the stated requirements of the project. When the requirements are established, each requirement must have a stated test. It is necessary that each requirement be testable, otherwise the requirement is pointless.

Implementation
The text is prepared and has been thoroughly tested, now is the time to create the documentation.

 * Publish - whether in paper form, online or as a CD-ROM, this is the phase in which the completed text becomes "live".

Maintenance
Although the main body of the text is complete, updates are inevitable. Feedback from actual users will also form part of the process for implementing changes.

 * Testing a document is an important quality assurance tool.

Training
Documentation development begins during the Planning stage of SDLC. When you write for development you write and participate as a team member in all aspects of development content. Developing process documents, proofing requirements, design, and technical specifications; and writing training documentation can be a part of your role.

Types of documentation delivery expectations for this stage:

Check list
 * Requirements Document
 * Design Document
 * Technical Specifications
 * Test Plans and Scenarios
 * Implementation Plan
 * Maintenance Plan
 * Training Specifications
 * Training Documentation
 * Support Documentation

Read More

 * Michael Knowles on Technical Writing

back to Technical Writing Level 1

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Technical writing/Edits


text:
Technical writing/Project management

back to Technical Writing Level 2

Planning
In the planning phase the system is created on paper.
 * Defining the proposed system
 * Scope – setting the project boundaries
 * Developing project plan – the what, when and who of the project
 * Managing and monitoring the project plan – tracking and validation

Analysis

 * Setting requirements - what are the tasks to make the system successful?

 * Requirement analysis – create priorities and define them in a document.

Design
Creating the actual design of the project

 * Design technical architecture – deciding the best technical designs to suit the needs of the project

 * Design systems model – creating the graphical world of the project.

Development
Building the actual product

 * Hardware – sourcing the materials needed to build the project
 * Software – coding.

Testing

 * Setting of test conditions - create a realistic test environment to eliminate bugs.

Implementation
The product is finished and ready for use by clients. This stage requires

 * User training

Maintenance
Keeping the system in step with the client through:

 * Customer Help Desk
 * Updates

Document Life Cycle
Document Life Cycle is a term used in Document Management Systems (DMS), Digital Rights Management (DRM) , Document Records Management Theory , Customer Relationship Management (CRM) , and Content Management Systems (CMS). The life cycle begins with the creation or receipt of the document and ends with its destruction or permanent preservation.

Writing a Technical Document
Creating an accurate and helpful technical document is a multistep process consisting of planning, drafting, revising, and testing. In most cases, a document will require contributions from a range of specialists including writers, designers, and subject matter experts. A project manager, sometimes called a Technical Writer Project Manager (TW PM), is the person overseeing the document’s creation.

Planning
The planning stage is the period in which the writers map the path for the completed document. As such, it will vary between writer teams but normally features a timeline for submissions and a budget estimate. Additionally, the planning stage includes:
 * Analyzing the expected audience for the document
 * Establishing the purpose of the document
 * Generating ideas for the document
 * Researching information for the document
 * Outlining the content of the document

Drafting
The drafting stage is the period in which the writer organizes information and ideas into sentences and paragraphs. Most technical writers will use a preformatted template at the start of the drafting process.

A technical document will normally undergo multiple drafts before approval. While some writers may still use pen and paper to draft, most will use a computer. The two most popular software tools for writing and editing are Microsoft Word and Google Docs. Other options include LibreOffice Writer, Dropbox Paper, Quip, Draft, and Hackpad.

Best practices advise giving all drafts a precise working title. The title should include keywords that describe the content. Precision in the title makes it easier for collaborators to manage the document. The working title is usually different from the final title.

Revising
The revisions stage is the period in which the writers edit the document. The process includes both line and copy edits (LINK). The first step in revising a document is always self-editing. Options for self-editing like spellcheck, grammar check, word count, and read aloud are included in word processing software.

After self-editing is finished, a writer will submit the document to other team members for feedback. The team will study the document and make suggestions for improvement. The writer will then incorporate their feedback into the draft and resubmit. The submit-critique-resubmit sequence can be lengthy but usually defers to the timeline agreed upon in the planning stage. Once the final draft is approved, the document will be sent to the publisher or the testing team (10.4).

Revising an existing, published, or live technical document normally requires less collaboration than a new document. This is because the revisions are additions, subtractions, or replacements of specific copy (e.g., a new disclaimer based on California Proposition 65) that do not alter the purpose of the document.

Testing
The testing stage is the period in which the writers learn how the intended audience responds, interacts, and uses their document. The process is called usability testing. Pilot tests, in which a single document is tested, are used to improve the reliability of the usability testing process. Properly conducted, a usability test will reveal the strengths and weaknesses of the document. The information gathered will be used to improve the document. The goal is to publish a technical document that’s helpful, informative, and intuitive.

The reason companies test documents is that effective technical documents save money. They reduce customer questions (phone, email, in-person). They reduce complaints and bad reviews. They reduce churn and product abandonment. Most importantly, they reduce accidents, even fatalities To collect valid data from a usability test, administrators need to stay organized. They must be attentive to participants, ready to answer questions as they arise. At the end of the test, they must debrief participants to clarify observations.

Once the team records the results for their test, they’ll send the document back to the writing team for revision. Upon final acceptance, the document will then be sent to the publisher.

Design
The design stage is where the actual look of the document is decided, as well as what will be included and left out.

 * How much detail is needed?
 * Are there any company standards?
 * Are there any industry or government standards/requirements? (Military manuals must meet certain Mil-Specs and commercial manuals may need to meet government or trade association standards)
 * What sequence should the information be presented in?
 * What elements are required for the document?

Develop
During the development stage, the document will take shape.

 * Authoring
 * Research
 * Planning
 * Naming conventions
 * Version control
 * Access control
 * Template design as needed
 * Authorization of template
 * Develop authoring guidelines
 * Develop training if applicable

Deliver

 * What form will the final output be available in?
 * hard copy
 * .pdf
 * CD
 * webhelp
 * Others

Capability Maturity Model (CMM)
CMM stands for Capability Maturity Model, a tool for improving processes.

The tool was developed by Software Engineering Institute at Carnegie Mellon University in Pittsburgh.

Its aim is to help companies improve their processes and establish best practice in a company.

According to this tool, there are 5 possible levels of process maturity.

Level 1 - Initial
The most basic level of process management. Decisions are made ad hoc, meaning there is little planning and the company environment is unstable.

Success is a product of competent staff rather than established processes. Level 1 companies do succeed, but they miss deadlines and go over their budget.

Companies operating at level 1 rely on highly skilled staff to succeed.

Level 2 - Repeatable
A level 2 company has implemented some processes into their project management. In particular they track costs and time in projects.

By having disciplined processes the company continues with practices even when under stress.

By tracking time schedules, level 2 companies can keep projects on course with major milestones although there is still a tendency to complete the project late and over-budget.

In projects which are similar, level 2 companies can repeat their success.

Level 3 - Defined
In level 3 the company has standardised processes which are established and being improved. As a result, there is consistency across the company. Individual projects are defined according to company policy.

The company sets objectives in line with their standard processes.

Level 3 has a greater scope of standards and procedures than level 2. Because a level 3 company has standard processes, individual projects are in line with those standards rather than individually defined.

The company ensures good project management by using quality project management software.

Level 4 - Quantitatively Managed
At level 4, companies are using well defined processes to control the project.

Most importantly, company management have the skill to adapt processes to individual projects without negative outcomes.

Level 4 takes level 3 further by judging process performance by statistics and other metrics to predict results.

Level 5 - Optimized
At level 5 process performance is improved by the use of innovative technologies.

Processes are measured against quantitive objectives, leading to improvement in both organisational standards and processes.

Possible improvements to processes are evaluated and implemented.

The company staff are aware of and identify with company values.

Learning is a vital part of the development of the company, the company quickly shares learning.

Level 5 differs from level 4 in dealing with the causes of process variation. Processes are then changed in order to improve the process.

More
For more detailed information about SEi and the CMM, visit www.sei.cmu.edu

“You can’t control what you can't measure” - Tom DeMarco

Metrics
Metrics are used to measure a number of variables throughout the project life cycle, including:

 * productivity
 * resources available and required
 * trends

Metrics are used to create key productivity indicators - to show just how effective a company is on the market place.

Why use them?
Metrics are used not just to measure the productivity of a work force or project, but also to set targets.

In order to fully use metrics the following information about each metric is essential

(Source of this table: ISM3)

Quantitative vs. Qualitative
There is a risk known as: "what you measure is what you get". If we count the number of pages, the chance is we get a huge amount of pages just to get a higher score. If we count words, it may happen to words, too.

The paradox is the properties of documentation that can be easily measured have little importance in regard to the real value of the document from the end user`s perspective. This is the case of counting the number of pages in the document.

Quantity is not Quality.

From the other side, it is more difficult to build a metrics for the attributes that in fact brings an added value to the document from the end user`s perspective. This is the case of: subject coverage by content, language style, enough level of details for the reader, etc...

Also, planning good metrics for the document quality must start at the phase of collecting requirements. If the document must be measurable then the requirements for the document must also be measurable. Only this way we can see if the requirements have been met by the writer and other players in the production chain. E.g. if the requirement is that we produce a good document, so how could we define the metric showing that the document is really good?

Requirements must be specific so that we know they are attainable. And the match between the content and requirements may be then used as one of the metrics used for measuring the document quality.

Other
Statistical information about peoples' work will be mined from CMS.

The management of workflow and supervision of all other activities will be based on those data.

All projects cost time and money.

It is important to accurately estimate how much a project will cost.

Most projects are late and more expensive than planned.

Cost and Time Estimates for Documentation
According to studies, documentation accounts for 10% of the total cost of a project.

Automated Estimating Systems
The use of automated estimating tools can greatly improve the accuracy of cost and schedule estimates, when compared to their human equivalents.

In most projects with a Function Point score of more than 10,000 the costs of documentation and defect removal are greater than that of creating the project itself.

Common Functions of Automated Estimating Tools

 * Estimate time and cost at phase, activity and task level
 * Makes adjustments for work periods, holidays and overtime
 * Considers local salaries and workload
 * Adjusts for project type
 * Supports Function Point, LOC metrics or both
 * Handles conversions between Function Point and LOC
 * Supports new projects as well as maintenance and upgrade projects

Advanced Functions

 * Estimates quality and reliability
 * Analyses risk and value
 * Estimates return on investment
 * Shares data with other project management tools
 * Assesses historical data according to measurement models
 * Supports process assessments
 * Provides statistical analysis for multiple projects
 * Currency conversion for international projects

Variable Factors
As all projects are different, there are factors which change according to the project. A good automated estimating system will take these variables into account.

 * Staff experience
 * Client expectations
 * Product type being developed
 * Size of deliverables
 * Project size
 * Design method used
 * Requirements method used
 * Available re-usable materials
 * Testing methods used
 * Overtime status - paid/unpaid

Example Estimating Tools

 * COCOMO II
 * CostModeler
 * KnowledgePlan

Task Tracking
It is vital during a project to make sure that the necessary work is being done.

This process is known as "task tracking"

It is important to track tasks to ensure a project stays on time and within the budget.

Avoiding scope creep is another valuable use of tracking.

With the same products being used around the globe, it is important to adapt products to local markets particularly where the original comes from a different culture and language.

The abbreviations are based on taking the first and last letters of the word, using the lower case form, and the number of letters in between.

i18n - internationalisation
Internationalisation is a process for making software which supports all the world's languages.

Such software must also be aware of local cultural norms and traditions.

i18n is the first step in the process of making a product suitable for varying cultures and traditions.

L10n - localization
Once a product has been internationalized, the process of L10n can begin.

The aim of L10n is to make a product suitable for cultures other than the one it was created in.

L10n takes into account factors such as:

 * language differences such as British and American English
 * different alphabets - Cyrillic, Hebrew, Arabic, additions to Latin
 * varying calendars - Islamic, Buddhist, Jewish, Gregorian etc.
 * measurements - metric and imperial
 * cultural traditions and customs
 * religious holidays

g11n - globalization
Globalization is the process where companies sell their products in many markets around the globe.

It is this which has led to the need for l10n.

 * L10n and i18n
 * Internationalization and Localization
 * Internationalization
 * Documentation Life Cycle PDF
 * SDLC
 * Cost Estimating Methods for Large Projects
 * Metrics
 * Using Metrics to Plan Documentation Projects

Scope
The scope of a project is the total requirements and features of the project.

Scope can also refer to the amount of work required to successfully complete the project.

Why is it important?
Understanding the scope of a project is vital to keeping a project on track.

Without clear targets and procedures it is easy for a project to become large and unwieldy.

This is known as "scope creep" and has a major impact on both the financial and time costs of the project.

Controlling Scope Creep
Scope creep is the adding of features to a project which were not in the original plan.

There are 2 types of scope creep:

 * Business Scope Creep - when requirements are added to a project to meet business needs.
 * Features Scope Creep - when extra features are added to a project by developers independent of management.

To control scope creep it is necessary to have a Scope Management Plan which clearly defines the procedures the project will follow. The Scope Management Plan is part of the overall Project Management Plan.

Features which fall outside the scope of the project are not added to the project automatically but must be assessed to see if they fit the requirements of the project.

Design
The design stage is when decisions of how a project will look are taken.

In documentation, the design phase is about deciding the following:

 * What will the document cover?
 * What format will the document take?
 * How will the document look?
 * In what order will information be presented?

Why is design important?
The design stage must take into account the needs of the audience, in order to create something appropriate to their task.

 * Goals
 * Quality
 * Schedule
 * Cost
 * Reuse
 * Audiences
 * Internal
 * External
 * Processes
 * Research and content gathering
 * Writing
 * Graphics
 * Editing and testing
 * Publication
 * Project Data
 * Risks
 * Pitfalls
 * Avoiding pitfalls

What are milestones?
A milestone measures two things:

 * When something should be done by
 * How much progress should be made

Why are they used?
During the project milestones are used to track progress.

Milestones should be set when the requirements are established.

Milestones within a project are intended as a guide for personal workflow.

What is delivery?
The end result of the documentation process is delivering the prepared texts to the person who needs them.

Who do we deliver to?
Like every part of the process, delivery needs to be tracked to ensure that the material reaches its target.

Sometimes the person we deliver to is not the end user.

For example if we prepare a help file for an online guide, the text is delivered to the programmers who create the file.

 * Scope creep
 * Cherryleaf Documentation Plan
 * Documentation and QA

back to Introduction to Technical Writing

back to Technical Writing Level 2

title: Technical writing/Project management


text:
Technical writing/Overview

 * How to edit Wiki

 * Wikiversity Main Page

 * Back to Technical Writing Level 1

Who is a Technical Writer?

 * "What is Technical Writing" - Warren Clendining, Mount Royal University Continuing Education instructor (YouTube Video)

 * Technical Writing in 20 minutes - Part 1, Cherryleaf (YouTube Video)

 * TWFred lecturing on the basics of writing a technical topic (YouTube Video)

Most professionals require some technical writing skills. In information technology, project managers and analysts write technical documents that must be clear and concise.

A technical writer explains the product to the end-user, by creating:
 * Technical and Software Manuals
 * Handbooks
 * Technical Guides
 * Online Help

Technical writing is mentally-stimulating, creative work, and requires someone who is both sociable and well-read. Technical writers do not need to know how to program computers or have more than a general understanding of the technology, but they must have the ability to learn about a new product and then explain it to others. Those with training in journalism, teaching, and writing can grow to become excellent technical writers by studying the techniques of modern technical communication. Often though, engineers and technicians most familiar with the technology, product, and process can have or develop writing skills to become technical writers.

Technical writers enjoy learning and reading. They find writing comfortable, though they aren’t perfect, and typically revise their work many times. They are both creative and orderly. Most importantly, they put themselves in the end user’s position.

This introductory course covers only the most universal and important concepts in technical writing. Later courses deal in depth with areas such as business analysis, documentation management, and other advanced topics.

What do technical writers do?
When technical writers approach a new piece of technology, they are inwardly observing their own lack of knowledge. As they interact with and learn the software, they identify the information needs of the software users. They must be able to communicate well with programmers and customers, and extract information from them in a professional and personable manner.

A technical writer's primary tool is language, tools such as Microsoft Word, FrameMaker, and RoboHelp; or—increasingly—free and open-source documentation software such as Wiki, are secondary considerations. In the course of their careers, technical writers learn dozens of other software packages and tools, and then teach them to others.

Worldwide, there is a strong demand for technical writers. Overwhelmingly, they use the English language. Software companies require technical and user documentation of their products, and will continue to do so for the foreseeable future.

It's difficult for aspiring technical writers to get “a foot in the door.” Most employers are looking for technical knowledge and demonstrated experience. Completing this course, and creating a project portfolio of completed work, will open doors to a career in technical communications.

Back to Technical Writing Level 1

{| cellspacing="0" cellpadding="0" style="margin:0em 0em 1em 0em; width:100%" Technical Writing at Wikiversity
 * style="width:100%; vertical-align:top; border:1px solid Gold; background-color:LightYellow;" |

The Essential Skills of a Technical Writer
A good technical writer requires six important skills or characteristics:

1. General ability to write

The most important skill is to be able to write extended essays easily. You can test this skill on NaNoWriMo. Also be sure to use correct spelling and grammar (you cannot use GRAMMARLY, MS Word, etc etc…on the exam. And the quiz only accepts answers spelled correctly.)

2. Facility with technology

You must have the potential to grasp technology. You may have a bent towards one of the sciences, and can understand the inner workings of cells or atoms. Or you may be web savvy and know how to interpret code. Or maybe you’re just curious about how things work. You can learn technologies you don’t understand, if you have the motivation. I personally enjoy learning about complicated systems. This understanding brings a sense of achievement and knowledge that is rewarding at the end of the day.

3. Ability to write clearly

The essential skill of any technical communicator is to disambiguate. The core job is to study complicated things and explain them clearly. You can’t just pass off an explanation without understanding it completely. Writing about something, as opposed to talking about it, requires you to understand it thoroughly. Avoid passive voice and long sentence constructions. Define acronyms and avoid assumptions about what the user knows.

4. Talent in showing ideas graphically

Show ideas graphically as much as possible. People understand better when you can communicate visually. Images help make your writing clear.

5. Patience in problem-solving/troubleshooting

Unless you have patience, you’ll never make it. Much of IT work consists of problem solving. It’s amazing how a seemingly impossible problem can be solved with a little patience and persistence.

6. Ability to interact with SMEs (Subject Matter Experts)

Interacting with SMEs is one of the most overlooked skills in technical writing. You must be able to identify and interview people who possess knowledge important to your document. You can’t be shy about going after certain people to extract information — and you can’t be too proud to ask “dumb technical questions.” Much of this interaction can come about if you’re lucky enough to simply sit near SMEs.

Thanks to Tom Johnson for permission to use this material. [Edited once for clarity in context.] For more see his website I'd Rather Be Writing - Five Skills Every Technical Writer Needs
 * }

Technical Writing Basics
You can use any word processing program to create printed user guides. Free and open source software like OpenOffice and LibreOffice are good, but many employers expect you to have experience with proprietary tools such as MS Word and Adobe FrameMaker.

To create online content, you may use a proprietary program like RoboHelp for help files, or a web authoring tool for making web pages. We recommend that you also explore how platforms such as Wiki can be used for delivering user oriented instructions.

Wikipedia defines Technical Communication as:

The process of developing information products in technical communication begins with ensuring that the nature of the audience and their need for information is clearly identified. From there, the technical communicator researches and structures the content into a framework that can guide the detailed development. As the information product is created, the paramount goal is ensuring that the content can be clearly understood by the intended audience and it provides the information that the audience needs in the most appropriate format.

This means there are always at least three steps in every documentation project:

 * 1) Identify the audience.
 * 2) Research and structure the content.
 * 3) Ensure it is accurate and understood.

| TWFred lecturing on the basics of writing a technical topic.

Technical Communication is a conversation
Lindsey Robbins of Blackbaud describes technical communication as a conversation between the user and the technical writer - the writer must anticipate the user's questions. Robbins says:

 * "Sometimes, your users or constituents won't know the correct question to ask. In those situations, try to think out the questions for them and answer them in advance. Provide them with the conversation starter and they're more likely to be engaged.

 * "And remember: People don't have an infinite amount of time. They really will only participate in the conversation long enough to get their answer. Therefore, all your communication, whether it's real time or not, needs to be concise, clear, and efficient. Don't provide lots and lots of text that users will balk at when they see."

Reprinted with the permission of Lindsey Robbins, from her article "Be Part of the Conversation".

Technical communication is the act of translating between user and developer, with the technical writer as translator. The technical writer understands what the developer wants to explain to the user about using the product, thus the technical writer bridges the communication gap between user and developer.

Technical Writing Myths
In an article on his blog, Tom Johnson refuted several common myths about technical writing and the skills a technical writer must have.

He believes the most common myths are:

 * 1) Technical writers spend most of their time writing.
 * 2) You can’t get a job in technical writing unless you have technical writing samples, but you won’t have samples until you have a job in technical writing.
 * 3) A technical writer who has years of experience is more knowledgeable than one with fewer years of experience.
 * 4) The tools you know are more important than your industry knowledge.
 * 5) Be careful about having a blog, because all employers google you and will find it.
 * 6) Technical writing academics are disconnected from the profession, and have only a tenuous idea about the actual practice of technical writing.
 * 7) You can’t have voice or style in technical writing. It must be objective. And the fewer contractions, the better.
 * 8) Technical writers aren’t allowed to contact users directly. They should get their information through the product manager, customer support, and marketing.
 * 9) You can single-source material into all the formats your audience needs if you just learn the right tool or technology.
 * 10) You must be quite tech-savvy to be a good technical writer.

For Tom's full treatment of these myths, see his article "14 Widespread Myths about Technical Writing".

This material has been re-published here in an edited form. Thanks to Tom Johnson for allowing us to use his articles here.

A great future
Technical Writers:

 * communicate ideas
 * design information
 * participate in the product development process
 * manage complex documentation projects.

Junior software technical writers are often responsible for communications between the developers and the end-users.

Business writing skills are useful for technical writers. All technical writers must write clearly, and communicate well with specialists. The field of Technical Writing is large and can be hard to define. For this reason these lessons concentrate mostly on technical writing for the software industry.

Junior Technical Writers produce the following types of documents:

 * Product brochures, web sites, and other marketing tools that explain the benefits of the software to buyers.

 * User Guides, manuals, tutorials, and step-by-step task lists that guide new users learning the software.

 * Installation and maintenance guides that show the administrator and experienced user how to configure and troubleshoot the software.

As you advance in your career you may find yourself writing more advanced documents:

 * Requirement Specifications that document the needs, goals, and environment of the users of the software.

 * Design documents that describe the workings and interactions of the system.

 * Control documents that communicate project standards, configuration, schedule and work tasks.

 * Test cases that detail the required functionality so the software conforms to the specifications.

Documentation management includes:

 * Cost and schedule estimating.

 * Complex documentation project administration.

 * Setting standards and procedures.

 * Information management.

As you can see, there is a lot of room to learn and grow in the profession of technical writing.

How to edit Wiki

Wikiversity Main Page

back to Technical Writing Level 1

title: Technical writing/Overview


text:
User talk:TWFred

Hi Fred, great resources on Technical writing! By the way, I've only just now seen your note to try to get in touch with Leigh Blackall - I know him quite well - and you can contact him through the email address on his user page, or through the "Email this user" link from the left-hand side toolbar on his userpage (provided you have set up and activated your own email - if not, you can do this through the "my preferences" beside your username when you've logged in). See you 'round.. :-) Cormaggio talk 12:16, 19 July 2007 (UTC)

Hello TWFred, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity! --Cormaggio talk 12:16, 19 July 2007 (UTC)

Page titles and redirects
Hi. There's some strange editing going on over at Technical writing - I'm trying to sort this out and work out what people are actually trying to do. If you'd like some help, please feel welcome to ask me. McCormack 10:18, 23 August 2007 (UTC)

Hi again, and thanks for your email message. I see that some of the other custodians have also been contacting different people in your class during the day. Your use of the mediawiki editing environment is a little strange, and I'm sure we all want to help you. We won't delete your pages! But you'll inevitably find that custodians will start trying to help correct your pages. Here a few guidelines for things you should and shouldn't be doing... If you do any of the above, you'll suddenly find a flock of well-meaning custodians descend from the sky, all trying to help you out of your troubles. If you need help in advance of a project day, you can ask on the Colloquium. McCormack 16:51, 23 August 2007 (UTC)
 * Don't use http://en.wikiversity.org/wiki/ to prefix page titles.
 * Don't use http://en.wikiversity.org/wiki/ inside links on pages - the correct syntax is to use double square brackets and then just the page title - i.e. PAGE_TITLE.
 * Don't redirect image pages. If you want to practice redirects, use pages inside the main namespace - i.e. normal pages.

about these edits on your user page ...
There were 2 attempts to change your user page: and. Since these are only with IPs, I removed them again. Could you please tell, if this is you or someone else ? If it is you, please login, otherwise w eboth waste time :-( Thx, Erkan Yilmaz ( evaluate me!, discussion ) 16:35, 17 September 2007 (UTC)

Good job
Hi, I see you are havily editing. It pushes me to participate more on the project.--Juan 12:48, 11 December 2007 (UTC)

Image copyright problems

 * Your currently affected images are listed below. For each, please provide a license template and source. Thanks. – Mike.lifeguard | @en.wb 23:35, 13 February 2008 (UTC)

 * 2007-08-02 08:22, TWFred: Onionpersona2.jpg: untagged! ; 0 (0)
 * 2007-08-02 08:23, TWFred: Onionpersona3.jpg: untagged! ; 0 (0)
 * 2007-08-09 14:45, TWFred: Robs picture.jpg: untagged! ; 1 (1)
 * 2007-08-09 15:17, TWFred: Robs picture2.jpg: untagged! ; 1 (1)

Nuke 'em all, Mike. Thanks for the clean up. TWFred 08:41, 14 February 2008 (UTC)
 * Thanks for being so positive about this necessary clean-up task. I'm not an admin here, so you'll have to grab one do to that for you. I've also replied to your email. – Mike.lifeguard | @en.wb 22:53, 14 February 2008 (UTC)

 * UPDATE: Got another "warning" that these are copyright violations.  Cool.  Wonderful.  But I asked for them to be deleted before...wonder why they're still there.  Oh well.  If there's something I should do, just let me know and I'll do it. TWFred 14:53, 20 August 2009 (UTC)

Out of my ears
Hi Fred, I just saw your comment on Colloquium, and left a brief response. I didn't know it was becoming like this for you. I'd be happy to work on a policy on this - and it might be worth bringing up on the Foundation-l mailing list as an issue that is raised quite often. Cormaggio talk 10:59, 25 February 2008 (UTC)

Spam filter
Hi, see the preliminary solution here please. Hope everything fine now ? Erkan Yilmaz uses the Wikiversity:Chat (try) 20:40, 25 March 2008 (UTC)
 * Left a note here so it could be replaced by another link ? Erkan Yilmaz uses the Wikiversity:Chat (try) 20:59, 25 March 2008 (UTC)

Portal talk:Engineering and Technology/ - Electrical/Electronic Engineering Orientation/Aptitude Course
ping - Thuvack 11:01, 10 April 2008 (UTC)

Aptitude, or Final Exam
Ping- Thuvack 05:44, 21 April 2008 (UTC)

Completed courses list
How would you like your courses listed in the list of completed courses? - Robert Elliott 05:01, 10 May 2008 (UTC)

Technical Writing
You're putting together quite the course there, Fred! I appreciate the work you've put into this—I happen to have a degree in English, and technical writing is a career I've considered. I also think that your approach to developing the course using personas is a very good idea. Anyway, just wanted to say good job. If you want any collaborative help with anything, send me a message. The Jade Knight 08:11, 3 September 2008 (UTC)

Quality
Hello Fred, someone left feedback here, Erkan Yilmaz uses the Chat (try) 22:01, 13 September 2008 (UTC)

Just to say, I did not like the feedback in the above link; you have built an excellent page. Some of the criticism was actually kind of weird. I have been doing technical writing for the past year (I spent the 1990s as a exec-level technologist on Wall Street). Use mediawiki to make the page, then use the Chrome browser to cut the text and then put the text into Google docs, and then use the Google docs email facility. That way the info is in a wiki all the time, as a repository. Please feel free to contact me, I have a partner in NY who has his own little global network.

If you find time, take a look at some of my wv ideas on my web page. I am involved in policy right now, and my reason for being here is psychology research, but I would like to develop work-related resources as well.--JohnBessatalk 18:58, 19 February 2009 (UTC)

re: What are the rules?
Hi Fred, I answered your question on my talk page here. PS: I moved your question as a new section at the bottom. HenkvD 19:20, 24 February 2009 (UTC)

Thanks for the song
But do you have an mp3?? Not much of tune in text ;)--JohnBessatalk 21:38, 28 February 2009 (UTC)

Unfortunately I have found that empathy studies tend to take a dark turn -- very quickly! It can be said that the problem with the world is a lack of empathy (which seems obvious) but the people lacking empathy need empathy just as everyone does, for life. But since they cannot give it, and since giving is no longer the majority human trait, then they feel they have to take it. This became apparent in the discussion group on Care2.com, and effectively silenced the group. Everything had been said in the group, but I wanted to create an activist group from the empathy concepts, and that is what was silenced. I wrote a paper on the negative side of the group called "night of the living dead." It was that bad (?!?!)

Just as a side note, as an activist I originally opposed rules against advocacy on Wikiversity, and actually got others to go along with me, but then I changed my mind. It is information that is power, and with correct information people can participate effectively in forming their communities. This by itself is a form of activism, and even an agenda for Wikiversity.--JohnBessatalk 02:31, 3 March 2009 (UTC)

title: User talk:TWFred


text:
User talk:Klaas van Buiten

Hello Patio, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity! --Cormaggio talk 12:17, 19 July 2007 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Patio. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Patio~enwikiversity that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:47, 17 March 2015 (UTC)

title: User talk:Klaas van Buiten


text:
User talk:S.A.A.RAJESWARMHURGAIYA

Hello S.A.A.RAJESWARMHURGAIYA, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity! --Cormaggio talk 12:19, 19 July 2007 (UTC)

Wikiversity screen saver
Hello, could you have a look here please ? Your suggestions would be very much appreciated. Erkan Yilmaz ( my talk page, wiki blog ) 17:36, 25 September 2007 (UTC)

Image copyright problem with Image:Brush.JPG
Thanks for uploading Image:Brush.JPG. However, the image may soon be deleted unless we can determine the copyright holder and copyright status. The Wikimedia Foundation is very careful about the images included in Wikiversity because of copyright law (see Wikiversity' Copyright policy).

The copyright holder is usually the creator, the creator's employer, or the last person who was transferred ownership rights. Copyright information on images is signified using copyright templates. The three basic license types on Wikibooks are open content, public domain, and fair use. Find the appropriate template in Image copyright tags and place it on the image page like this:.

Please signify the copyright information on any other images you have uploaded or will upload. Remember that images without this important information or giving false information can be deleted by an administrator. If you have any questions, feel free to contact me, or ask them at Colloquim. Thank you. – Mike.lifeguard | talk 23:30, 28 September 2007 (UTC)

Image copyright problems

 * Your currently affected images are listed below. For each, please provide a license template and source. Thanks. – Mike.lifeguard | @en.wb 23:23, 13 February 2008 (UTC)

 * 2007-07-20 04:03, S.A.A.RAJESWARMHURGAIYA: Pstamp.JPG: untagged! ; 1 (1)
 * 2007-07-20 04:39, S.A.A.RAJESWARMHURGAIYA: Slice.JPG: untagged! ; 1 (1)
 * 2007-07-20 04:39, S.A.A.RAJESWARMHURGAIYA: Sliceselect.JPG: untagged! ; 1 (1)
 * 2007-07-20 04:51, S.A.A.RAJESWARMHURGAIYA: Spotheal.JPG: untagged! ; 1 (1)
 * 2007-07-20 04:55, S.A.A.RAJESWARMHURGAIYA: Patch.JPG: untagged! ; 1 (1)
 * 2007-07-20 04:57, S.A.A.RAJESWARMHURGAIYA: Redpatch.JPG: untagged! ; 1 (1)
 * 2007-07-20 05:10, S.A.A.RAJESWARMHURGAIYA: Penciltool.JPG: untagged! ; 1 (1)

title: User talk:S.A.A.RAJESWARMHURGAIYA