documentation best practices

[Grant Hogarth]

I think you are right about all of this.
It's marketing fertilizer.
If you have documented (via emails, memos) the risks, then you are
covered, even if the company is not.
Aspirational material needs that disclaimer that stock prospectives have
( and I don't think your boss will want that legalese....<g>)

Grant

-----
Nadine wrote:
> That's what I was thinking. It sounds more like marketing copy than
> user guide content.
>
> Nadine
>
>     ------------------------------------------------------------------------
>     *From:* Jeff Coatsworth <jeff.coatsworth at jonassoftware.com>
>     *To:* "framers at lists.frameusers.com" <framers at lists.frameusers.com>
>     *Sent:* Monday, December 5, 2011 5:21:46 PM
>     *Subject:* RE: documentation best practices
>
>     It's called "marketing" ;>)
>
>     ------------------------------------------------------------------------
>     *From:* framers-bounces at lists.frameusers.com
>     [mailto:framers-bounces at lists.frameusers.com] *On Behalf Of
>     *hessiansx4
>     *Sent:* Monday, December 05, 2011 5:56 AM
>     *To:* framers at lists.frameusers.com
>     *Subject:* documentation best practices
>
>     I could use some insight into a situation I haven't encountered
>     before today: how does one best respond to a request (read: order)
>     to include something in their product's documentation about a
>     functionality that will not be released with the upcoming
>     release (it will still be in development) but is hoped to be ready
>     "shortly" (whatever that means) after the product is released.
>      
>     I've politely pointed out that industry best practice is to
>     document what IS as opposed to what WILL BE and that certain
>     liabilities might be incurred if promises are made and then
>     something goes wrong.
>      
>     Any thoughts?
>