| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 155.1 | | MOIRA::FAIMAN | Ontology Recapitulates Philology | Wed Dec 02 1987 09:40 | 38 |
| > What are the mechanisms in DEC for:
>
> a) finding out if yet-another-VAX-language is on the way
Well, unannounced new products are usually not for public
discussion. Some products under development have their own notes
conferences. If you're interested in a particular language,
you could start by looking in EASYNOTES.LIS to see if there is
a conference about that language, and if there isn't then you
could ask here. If you just want to know "what knew languages
are being developed," then I'm afraid you're out of luck.
> or
>
> b) seeing if you can cast your SPR to initiate same
You find someone in an organization which would logically have
the charter to develop such a product, and then you convince
them to convince their management that it would be worthwhile.
> [aside]
>
> c) how do you file an internal SPR on a language or product ?
Most languages and products have NOTES conferences. For
"traditional" languages (not AI languages), TLE::language-name
or CLT::language-name is a good guess. Even better, look in
EASYNOTES.LIS, the listing of all open conferences on the network.
The procedure for reporting bugs in the product should be described
somewhere in the first couple of notes in the conference. Some
groups have a NOTES conference for bugs, some prefer to receive
bug reports by mail, and some have a QAR system.
Note: EASYNOTES.LIS is posted as notes 2.* in
TLE::EASYNET_CONFERENCES (press KP7 or SELECT to add it to your
notebook). Language conferences are listed in note 2.6.
-Neil
|
| 155.2 | | TOKLAS::FELDMAN | PDS, our next success | Wed Dec 02 1987 11:31 | 24 |
| >> b) seeing if you can cast your SPR to initiate same
>
> You find someone in an organization which would logically have
> the charter to develop such a product, and then you convince
> them to convince their management that it would be worthwhile.
That's the engineering-driven method, which is the traditional way
new products get done at DEC, especially in the languages groups.
The alternative in the new DEC is to contact an appropriate marketing
group, show them the customer demand, and get them to instigate
the work. I don't know of any languages that were developed this
way, but I'm sure some other products were.
The last alternative, if you have a large customer demand, is to
elevate the issue through the appropriate sales channels. I can think
of at least one project that owed its existence mostly to a single
large customer.
While some products evolve out of internal needs (VAX Notes, for
example), I think it highly unlikely that internal requests for
a new language will get much response at this point in time.
Gary
|
| 155.3 | | AITG::VANROGGEN | | Wed Dec 02 1987 13:16 | 5 |
| For "AI languages", try prefixing AITG::.
The NOTES command DIR/CONF might help too.
---Walter
|
| 155.4 | | PSW::WINALSKI | Paul S. Winalski | Sat Dec 05 1987 20:11 | 33 |
| RE: .0
> a) finding out if yet-another-VAX-language is on the way
Contact Software Development Tools Product Management, which has responsibility
for nearly all of the compiled languages at DEC. Artifical Intelligence
Technology Group's product management would be the place to go for AI languages
such as LISP, Prolog, OPS-5, and Smalltalk. The manager of SDT Product
Management is Celeste LaRock (TLE::LAROCK).
> b) seeing if you can cast your SPR to initiate same
DEC-internal folks should rarely, if EVER, submit SPRs. There is a large
overhead expense involved with tracking SPRs that can be almost entirely
avoided for DEC-internal users on most products. Unless you are submitting a
problem report on behalf of a customer, or work being done under contract for
a customer, you should use the QAR (quality assurance report) mechanism for
reporting problems and suggestions.
Initiating development of a new language product can be accomplished by
contacting somebody in the appropriate development or marketing group. NOTES
is helpful for finding out who to contact.
> c) how do you file an internal SPR on a language or product ?
As stated under b), generally, if you are DEC-internal, you should not submit
SPRs. Most of the language products have set up a QAR system for that purpose.
Some prefer to get problem reports via NOTES or MAIL directly to the developers.
The particulars will vary depending on the product. The NOTES conference on
a product is a good place to look for the internal problem reporting
mechanism.
--PSW
|