TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: What is not mandated is forbidden From:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> To:Steven Jong <stevefjong -at- comcast -dot- net>, TECHWR-L Digest <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 23 Jun 2014 15:12:27 -0400
In systems where more than one person might have a hand, either serially or concurrently, it's very possible that a given user wouldn't get to see what the default is (if they aren't explicitly told). S/he'd get to see what somebody else had set. They might like to know the likely effects of modifying the current settings in one direction or another, either to decide whether to update what they inherited (config-wise) or to argue/discuss with other admins about their current setting choices.
And, absolutely, you are describing real situations.
I made a table for my readers, showing how logging level and log-file roll-over settings interact to affect disk-space and other aspects of performance.
But........ that was before we started getting serious about agile development and tracking methodology, now that I think of it.
-----Original Message-----
From: Steven Jong
I think the original question touches on the premises of minimalism. As such, it's interesting to discuss.
Imagine a product with event logging. You can set the logging level to five values, from terse (fatal errors only) to chatty (debug messages for every event). Minimally, you can document that there is logging, there are five levels, here they are, here's the default, and here's how to set them.
By the principals of minimalism, that's all you need to say. (Maybe even that is too much. Here's how to set log levels. Go explore! Customers will see the default at once, and they can determine for themselves what works for them.)
But it may be that setting the logging level to "terse" results in important errors, such as the system hanging, going unrecorded. It might also be that setting the logging to "chatty" floods the log, fills the disk, and ruins performance. It may be that customers call Support all the time with both these problems. (And it may be that I'm not making this up, but rather describing real situations 8^)
Perhaps I misinterpret minimalism. But I'm not misinterpreting the product line manager who would say not to include such a statement: he's wrong. Good advice is valuable; I care to minimize support costs; I care to maximize doc value; I care to improve the user experience; I care to just plain do my job. From any of those perspectives, I would include the information, both my example and yours.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.
