| Hello Barbara,
I'm sorry i've taken so long to respond to your mail. I'm referring to
your reply to note# 7130 in digital_unix.
I'm happy to hear that you are aware of the problems Peter and I mentioned,
however, but I'm not convinced that enough is being done. In particular,
you said:
> HTML and Bookreader files: The strategy of UBPG Publications is
> to move all Bookreader documentation to HTML as quickly as
> possible. I think we did an admirable job in Platinum, being
> the first major UNIX vendor to distribute HTML documentation
> with our product. Unfortunately, there are still Bookreader
> docs from groups outside of UBPG Pubs that the user must leave
> the browser and invoke Bookreader to view. We hope that in PTC,
> the APCD user interface will support accessing Bookreader from
> inside the HTML browser.
>
In my (humble) opinion, this is unacceptable, and very unprofessional.
Our users should not be required to use 2 completely different
applications to read our on-line docs, even if one can be called
from the other. It's peripheral stuff like this that gives
Digital UNIX a bad reputation.
> In the APCD Packaging Plan, we will recommend that layered product
> groups submit documentation to the Digital UNIX kit in a particular
> format. Documentation must be organized according to the the APCD
> layout guidelines (described below). It is the responsibility of
> Release Engineering and the group delivering the documentation to
> ensure that the the guidelines and recommendations are followed.
> To the extent that they do that, we will have consistency.
>
There are occasions when chaos and anarchy are useful, but this is not
one of them. We MUST deliver consistent, integrated documentation. It
is not acceptable to leave it up to the "group delivering the
documentation to ensure that the the guidelines and recommendations are
followed." This is a recipe for failure at DEC. There badly need to be
mandatory guidelines, and a mechanism to enforce them. I think my
example of kits is appropriate here: ALL software that digital supplies
for Digital UNIX is in 'setld' format. I'm sure that if some group
tried to weasel a tar format kit into the distribution, (unless it had
very good reasons for doing so), the kit would simply be refused. So,
if it can be done for kits, there's no reason why it can't be done for
docs. The customer isn't interested in hearing that group XYZ couldn't
be bothered to conform to the documentation standard. He wants to deal
with digital as a single entity, and we should strive to appear that
way.
I suppose one of the reasons that I'm responding now is that i've got a
bee in my bonnet: I was very recently thwarted in an exceedingly
frustrating way by the doc CDs: I will by flying to the states next
week to visit a partner in NJ to get the partner's software running on
TruCluster. I was going to take the Multi Media expansion box for my
HiNote Ultra so that I could read html docs even if I don't have access
to an alpha running UNIX (I've got FreeBSD on my HiNote, but Win95/NT
is in exactly the same position). HOWEVER, because the cursed doc CDs
(and AP 1+2, and LP 1-4) use UFS. ARRGGH. There's no point to using
UFS on those CDs, and lots of reasons to use CDFS. The only CD that
must be UFS is the BOOT/base OS CD, and it probably doesn't even have
to be UFS.
So how about it?
> However, we do care about how they impact our users and we do
> particpate in packaging, kitting, and distribution decisions
> when we can. Please continue to let us know how we're doing.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that was your mistake :-).
Regards,
Rob Urban
|