Re: Future use

["Bergerson, Carl A" <Carl -dot- Bergerson -at- UNISYS -dot- COM>]

        Kimberly wrote in response to Marci:
        >>I am in a very similar situation. I am trying to document a
constantly
> changing software product with changing priorities and changing
> schedules.<<
>
Is there another world?

        >>Does anyone have any tips for working effectively in this
> situation?<<
>
Yes, I do.

To put it simply, don't mention items that are not in the current
version; that serves no useful purpose. If that information belongs
anywhere, it's got to be in marketing literature or the red herring
stuff for the investors.

As to the features being de-implemented, you should give your customers
one or two releases to plan for this. State in the release notes when
the feature will go away and what new features take its place. Provide
examples of old versus new code (procedures, whatever) unless it's
painfully obvious. Better yet, even if it's painfully obvious.

Carl Bergerson
Mission Viejo
Product Information
carl -dot- bergerson -at- unisys -dot- com

> ----------
> From:         Kimberly Green[SMTP:kimberly -dot- green -at- CHEETAHNET -dot- COM]
> Sent:         Tuesday, February 24, 1998 5:53 AM
> To:   TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject:      Re: Future use
>
> Marci,
>
> We use "Not available in Version 1.1" (the version number for the
> release we are documenting). This is not a positive selling phrase, it
> just states the fact and does not promise anything.
>
> I am in a very similar situation. I am trying to document a constantly
> changing software product with changing priorities and changing
> schedules.  Does anyone have any tips for working effectively in this
> situation?
>
> Thanks,
> Kimberly
>
>         ----------
>         From:  Marci Abels[SMTP:mabels -at- CSIKS -dot- COM]
>         Sent:  Tuesday, February 24, 1998 8:34 AM
>         To:  TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>         Subject:  Future use
>
>         Hello,
>
>         I know this has been discussed before, and I've looked in the
> archives
>         and am still looking for a better way. We are documenting a
> developing
>         software package. Several features are not yet operational,
> though they
>         are planned for future implementation, some features are on
> the
> menu but
>         not operational because they are now obsolete, as far as the
> programmers
>         are concerned, and some features are still up in the air
> regarding
>         future implementation.
>
>         In the past, I used "For future release" which served us well.
> This
>         iteration, however, we have several features that will go
> away,
> some of
>         them were operational in the past but are no longer so. Some
> were
>         planned for future implementation, but have been dropped from
> the
>         planning schedule for various reasons. And sill others will
> eventually
>         be implemented, as soon as the programmers have time. I tried
>         "Implementation currently under review" but we have some
> people
> who
>         dislike that. So, I am looking for a statement to use that
> holds
> no
>         promises for the future, but says "Don't bother with this, it
> doesn't
>         work now." Of course, we wnat something more positive than the
> simple
>         truth, that the feature is not operational and we don't really
> know if
>         it ever will be.  :-)
>
>         I'm on digest, so if you have any ideas for me, please send
> them
> to me
>         and I will summarize for the list.
>         --
>         Marci Abels
>         http://www.geocities.com/Heartland/Acres/2592/
>         CSI, Inc,
>         http://www.csi.com
>
>
>
> ~~
>         Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> TECHWR-L)
>         Search archives at:
> http://listserv.okstate.edu/archives/techwr-l.html,
>
>
> ~~
> Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> TECHWR-L)
> Search archives at:
> http://listserv.okstate.edu/archives/techwr-l.html,
>