[comp.realtime] Reorganisation Proposal

randall@Virginia.EDU (Ran Atkinson) (04/14/91)

[ I edited a bit for brevity and clarity.  ran]

alex@telecdn.uucp (Alex Laney) originally wrote:

% I would like to put forth the proposal to rename the following newsgroups...
% 
% comp.cog-eng      --> comp.software-eng.cognitive OR 
%  		       comp.software-eng.user-interface
% comp.groupware    --> comp.software-eng.groupware
% comp.multimedia   --> comp.software-eng.multimedia
% comp.object       -->  comp.software-eng.object
% comp.realtime     --> comp.software-eng.realtime
% comp.software-eng --> comp.software-eng.misc
% comp.spec*s       --> comp.software-eng.specifications

Peter da Silva <peter@taronga.hackercorp.com> responded with:

>How about using the existing comp.sw hierarchy?
>
>	comp.sw.engineering
>	comp.sw.cog-eng
>	somp.sw.groupware
>	comp.sw.multimedia
>	comp.sw.object
>	comp.sw.realtime
>	comp.sw.specifications
>	comp.sw.components
>	comp.sw.misc

I like Peter's proposal a bit better on namespace grounds.

Maybe we could get comp.soft-sys.andrew migrated to some more
conventional space at the same time.  It is an inet-only group, so
normal USENET procedures do NOT apply to it.

comp.sw.specifications might reasonably be shortened to comp.sw.specs,
but it needs to be determined whether comp.spec*s currently is
software only or also includes hardware.  If it includes hardware,
it not might be appropriate to touch.

It needs to be determined whether comp.realtime has a mix of
hardware/software traffic before this proposal gets finalised.  
If it includes hardware traffic and isn't excessive in volume, it
should not be renamed.  If it has both and has excessive traffic, it
might be better split into two groups: comp.sys.realtime and
comp.sw.realtime.

Another idea would be to have a comp.hw.* heirarchy along these lines,
and create comp.hw.misc as a new catch all group:

  comp.arch     -->  comp.hw.arch
  comp.realtime -->  comp.hw.realtime
  comp.spec*s   -->  comp.hw.specs
 
  [ others also possible here ]

If this proposal gets finalised, it is clearly a candidate for a 
parallel vote.   An all-in-one vote would not be appropriate here,
because there would be too much change and potential for ram-rodding
private agendas.