RE: What is not mandated is forbidden

Subject: RE: What is not mandated is forbidden
From: "McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
To: Mike Starr <mike -at- writestarr -dot- com>, "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 23 Jun 2014 15:00:51 -0400

Starting from a history of waterfall-ish development, and after more than two years in-progress, we are in water-agile-fall(**), trying to get to agile, and one outcome of that is that EVERY new thing I add to the docs is supposed to be captured as some kind of Jira issue (story, bug, task...).

So, I never used to ask permission, and now I still don't, directly, but the indirect effect is that that's how it now works.
I have (as we say around here) a whack of issues in my backlog that aren't assigned to any sprint, that aren't supposed to be implemented unless I've got nothing to do. That doesn't happen, of course.

In reality, they'll get snuck into a DOC sprint that we writers are assigning to ourselves, packed among structural and other sanctioned stories and issues. But I thought I'd check which way the winds blow for the rest of y'all*. :-)

(*I'm not southern - I just like to say "y'all" sometimes)
(**actually, some product teams, here, are frighteningly agile, while others are still getting onboard - I'm in two that are at different places along that spectrum; if I had rhythm, you could call what I do "dancing"... but no )

-----Original Message-----
From: techwr-l-bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+kevin -dot- mclauchlan=safenet-inc -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Mike Starr
Sent: June-20-14 6:39 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: What is not mandated is forbidden

I never ask permission to put something into a document that can not only help the user but help reduce support queries. If you ask permission, you're just telling them to say no. Had you just put it in there chances are good it wouldn't have been flagged as "out of spec".

Best Regards,

Mike Starr, Writer
Technical Writer - Online Help Developer - WordPress Websites
Graphic Designer - Desktop Publisher - Custom Microsoft Word templates
(262) 694-1028 - mike -at- writestarr -dot- com -
President - Working Writers of Wisconsin

On 6/19/2014 12:14 PM, McLauchlan, Kevin wrote:
> Does everyone subscribe to the notion that customer docs should contain only what is necessary?
> Is there a place for material that is good to know, or that might reduce customer inquiries, but is not necessarily critical to performing a task?
> The most recent example that prompted this thought was a statement in an e-mail thread (internal) where a PLM stated clearly and succinctly how 'discovered vulnerabilities' are handled for our products. I know that the question comes up, in different forms, with some regularity, so I asked if it would be good to include the two-sentence statement in the main customer docs. The answer was that it wasn't really necessary in the docs, as it was "marketing-speak to show how secure our stuff is". In a sense, that's true, but it was also a quick, clear description of the procedure we go through, and what the three possible outcomes are.
> I didn't push, because it wasn't terrifically important, and not every battle is worth fighting. But, as it stands, that statement exists only as guidance for techs and sales engineers to respond to customers who ask. So, by that point, there's already a call in progress. If they had seen the info in the docs, the call might never have been made.

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.

Learn more:


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

What is not mandated is forbidden: From: McLauchlan, Kevin
Re: What is not mandated is forbidden: From: Mike Starr

Previous by Author: RE: What is not mandated is forbidden
Next by Author: RE: What is not mandated is forbidden
Previous by Thread: Re: What is not mandated is forbidden
Next by Thread: Re: What is not mandated is forbidden

What this post helpful? Share it with friends and colleagues:

Sponsored Ads