Oil well fires are stationary points of flame a few tens of meters wide - lots of pressure behind them, but not much territory, and a single point of combustion where the fuel is coming out of the pipe. You can surround them.

Wildfires have flame fronts that are hundreds to thousands of meters wide, irregularly shaped, with a wall of flames and fuel sources that may be 5 to 30 meters high (or higher), and can be moving 60kph or more.

Look at this picture: http://media2.abc15.com//photo...

Tell me where you will put the bomb to blow that fire out.

Perhaps for programmers the need is not evident, but for anyone who writes long documents, it's indispensable. It's indispensable enough that I am still using Microsoft Word for anything that has any sort of header/subheader structure. OO and LO are OK for short letters and memos, but if it has more than 2 headings it gets clunky because of the lack of outline mode.

The core difference between writing text and writing code, which apparently the programmers working on OO and LO fail to grasp, is that writers are producing text which will be read by humans, not executed by machines.You can't just comment out the cruft and do a GOTO jump over that module you decided you don't want, then tell them to go back 17 pages to pick up the information in paragraph 3. Writing needs structure and flow to lead the reader through the material in a way that make the content comprehensible. It needs primary and subordinate ideas. Order and levels of importance are important. In Microsoft Word, collapsing the document into Outline mode and seeing the heading and subheading structure makes the flow of the document visible, and more important, the means to change that flow is on the same screen. There is no interruption in the work flow.

http://www.gigamonkeys.com/code-reading/ seems to understand it, going the other direction: most real code isn't actually in a form that can be simply read .... in order to grok it I have to essentially rewrite it. I'll start by renaming a few things so they make more sense to me and then I'll move things around to suit my ideas about how to organize code. Pretty soon I'll have gotten deep into the abstractions (or lack thereof) of the code and will start making bigger changes to the structure of the code. Once I've completely rewritten the thing I usually understand it pretty well and can even go back to the original and understand it too.

Which leads me to "Issue 3959", wherein writers asked for this on 2002-04-10 20:39:19 UTC ... it's ranked as "Trivial" now. It has nothing to prevent implementation except the inability of the code maintainers to accept that writers really do know what they need in their tools.

Here's the overview of Bug 3959 ... https://issues.apache.org/ooo/...

OVERSHOOT wrote upstream: Ah, yes. Issue number 3959. Originally filed April 10, 2002. More than twelve years ago. In that time it has remained in the top-voted issue list year-in and year-out. Others come and go, but 3959 keeps on pissing off users. At last look, there are about ten duplicates requests on file.

Every few years some developer wanders by and tells the people following it that nobody needs outline view, or that there are tools available to do it, or whatever. Often, they close the issue. In effect, "I don't use outline mode so obviously it's not important." The mailing list heats up for a while, the developer either mumbles something about maybe the team should look into it and vanishes or else just vanishes, but the issue is either reopened or left open. I've seen at least four of those cycles so far. We're probably due for another one.

At this point, I suspect that 3959 will outlive (Open|Libre|Star)Office for the classic open-source software reason: if it doesn't scratch a developer's itch, it ain't happening. And apparently, developers don't outline, edit, or otherwise structure their writing or much care about the people who do.

As the wisdom of XKCD proves - http://www.xkcd.com/619/

This may explain why the incredibly ancient feature request for an "Outline View" in OpenOffice has gone over a decade (Reported: 2002-04-10) with no resolution.

https://issues.apache.org/ooo/...

The mental mapping of code for programmers and the mental mapping of text to those of us who write literature and non-fiction is totally different. They can't visualize how an outline and headings and the cues fonts give readers differs from all the "mind maps", "document navigators", and other inadequate replacements they keep suggesting will fill the need.

At the base of Pike's Peak, 6th Thursday in November. Drive the vehicle of your choice. Hogs will be provided.

First person to haul an aggregate weight of 1250K in hogs to the top wins. There is no limit on the number of trips, but all hogs must arrive at the toip for the vet inspection in good health.

From TFA: The purpose of technical documentation is to take someone who has never seen your project, teach them to be an expert user of it, and support them once they become an expert.

Definitely NO, and even HELL NO! It's to make it possible for them to use the product at the level they were hired to use it at, or for the purpose they bought it for. My auto's user manual is a USER manual, not a service manual and not an automotive engineering textbook.

I've been writing technical documents since the early 1970s.

You can't expect one piece of documentation to serve everyone ... it's like buying a "vehicle" and trying to use it to race, haul hogs, and climb Pikes Peak.

A - Ordinary users don't give a shit how the stuff works, they want it to do something for them ... tell them how to make whatever it is work as a tool for them. Run through the common use cases, screen by screen, showing them how to make the widget-smasher do it's thing.

Start with things the way they should work, then give them some basic troubleshooting, maintenance, etc.

B - Administrative users: They need all of "A", and how to handle the other users. Add, remove and monitor users.

Start with things the way they should work, then give them some basic troubleshooting, maintenance, etc. for the added functions.

C- Service techs, sysadmins, and those who will touch the sacred code: All of A and B (be reference to the appropriat4e manual or section thereof) and then feel free to pile on the technocrapobabble.

Each detailed explanation should start with a very brief "statement of purpose" ... when will this command be needed, or what does the bit of machine do. Why would you use it?

Then explain how to use it, and the expected results if you used it right, the expected results if you screwed up, and how to recover from an error.

========
You need to explain for each level of user what happens to a transaction, or data, or a part being manufactured, as it passes through the process or the proigram ... chronologically, what touches it and what is supposed to happen?

What will you see if there is a failure?

How do you recover from the failure?

It's not difficult, you just have to make sure that each level of user can get their task done efficiently.

Way back, in the dim, distant past of the bucolic walled gardens that preceded the Internet as we know it ... there was AOL. AOL had walled predator-free gardens within gardens, where only teens younger than 18 were supposed to be communicating.

There were rumors that evil pedophiles were lurking in these gardens, so I made a sub-account for a totally bogus 16-year old boy named Alex. And Alex went forth to play.

All was going well, Alex was quite a popular young man amongst his peers and had lured ZERO pedophiles when he got this e-mail from a fellow writer: "Alex, are you Tsu?"

BUSTED ... not because of subject matter or vocabulary, but because of a @#$&%^ liking for compound, complex sentences and other arcane constructions ... and using them accurately.

Tools like this basically do: (step 1) build abstract representation of text - (step 2) rebuild it into a new text using random substitutions.

Those are easily spotted by their near-miss of English. It's called "content spinning" and it is easy to spot.

Coccidiomycosis is all over the southwest, it's not incurable, and it's no flipping mystery why the incidence is increasing ... A couple of wet winters, some dry dusty summers and an influx of new residents with the attendant construction kicking up the dirt where the spores are ... and probably an easier diagnostic test. Instant epidemic. We had a surge of cases every fall in Phoenix if the dust storms had been severe.

2/3 of the people who have antibodies against it thought they had a slight cold or had no symptoms. A large chunk of the remaining 1/3 have a mild cough and mild to moderate fatigue ... I had it and it was fatigue of the "stop and rest three times going up one flight of stairs" kind. A serious damper on my college life for a couple of months.

It's been known for decades (since before I took Mycology in the late 60s) that certain groups were more prone to have severe cases: African Americans, Asians (especially Filipinos), Women in their 3rd trimester of pregnancy, People with weak immune systems, including those with an organ transplant or who have HIV/AIDS

Moving a group of people out of an area where they are extremely likely to get a disease that will make them sicker makes economic sense ... fewer cases of the illness means fewer resources needed to take care of them. But I'd screen them for antibodies first, because only the non-immunes need to be moved. I'd bet that over half to prisoners they plan to move are already immune.

==========
A vaccine was under development during WWII, but the project stopped when the war ended. There have been noises about reviviing the project, but no funding.

It's not just "let's get started, folks". There are intra-song cues and signals coming from the conductor's baton that must be detected - instructing a small group of instruments or voices to start and stop independently of the rest of the group, instructions to hold and fade a note, instructions to chop off a long finale ... it's a complex and almost entirely gesture-based communication.

However, when it comes to the very moment of starting, or the change of tempi, my start will always come too late.

Ah .. the trauma of remembering band practice:

Every conductor has a different style. The signal to start your part of a song that has already begun may be a small flick or pointing of the baton in your general direction, barely interrupting the overall tempo of the conducting, or if you have a dramatic conductor it can be a two-handed "picador going over the horns" gesture ... or no gesture at all.

Because the baton may be signalling to someone near the OP - in front or behind - but not the OP, the problem is discrimination as much as detection.

Also, it's not always a down beat. Changes of volume, extended notes and the final cut off of a long final note may be sweeping or tiny gestures sideways or straight towards the choir or orchestra.

Very few conductors will make big changes in tempo from what was practiced. No good will come of it.

In short, it might be more practical to start on the second note and drop out on the next to last note, paying attention to the parts of the production that immediately precede your bits so you are ready for it.

Almost every university has a technical writing department. Those students often need real-world projects for their classes.

Call the professors and ask them if they would like some real-world software for their students to document.

I used to get paid to WTFMs. If there was a good functional specification for the hardware or software, I could have the first draft done about the same time the early testing started, and much of it was lifted from the specs. You don't have to see it working to describe what it is supposed to do.

If I had to WTFM for something with a bad spec or no spec, something that was being developed ad hoc ... it took a lot longer.

So when will they implement [Bug 3959] Outline View. It's been on the request list for 10 years, has 343 votes, and it's the only thing that keeps me using MS Word.

I'll edit books for pay if you have the money up-front, but if I were expected to work on contingency (not being paid until the book sells, and only getting a portion of the sales) I would reject all books that didn't have a chance at making it ... just like a real publisher. If Amazon were paying me to edit books, they would want me to reject books that are unfixable, those books that wouldn't make enough money to pay for the cost of my editing services and their overhead ... just like a real publisher.

So how will your deal with rejection?