New tag proposals from iterating.org (1/2)

[Justin B Rye]

Enrico Zini wrote:
> We have a field::electronics.  We can consider that it suffices for home
> automation, but field::electronics gives me more the idea of something
> to study electronic equipment rather than of something to drive them.
> 
> To me, it fits under hardware.  Something like hardware::nerd, but
> meaningful.

Plain hardware::electronic, or ::gadget, or ::hobby?

> > > "Event Automation Tools"
> > > 	no mapping.  We need it for packages like cron, anacron,
> > > 	fcron...  PROPOSED: admin::scheduling
> > Only the clock-based ones?
> 
> Good point.  Something for more general "process management" (scheduling
> job batches, monitoring execution and running new programs in a chain
> when some predepending programs terminate...) would be neat.
> Can you think of a word for it?

admin::automation?

> > > "Virtual User Interface Software"

I missed this first time round; is this
a) the virtual rather than physical desktop UI I'm already using, or
b) vapourware?

> > > "Virtual Machine Software"
> > > 	We indeed miss categories for virtualization tools.
> > > 	PROPOSED:hardware::virtualization? Or admin::virtualization?
> 
> I decide for admin::virtualization.  hardware::virtualization could just
> be filed under hardware::emulator.  And if software appears to fiddle
> with registers of virtualization-specific chips, we'll create
> hardware::virtualization as well.

::v12n!  Or hw::vm.  Still, I suppose users won't be typing it.

> > With this and the last, if a tag is turning up in more than one of
> > the "specialist use" facets, maybe it should be given a generic
> > use:: tag.  Though not unless some examples turn up.
> 
> I concur.  Are you proposing use::administration?

No, "this" was ::versioning, "the last" was ::issuetracker, but I
don't think either quite deserves to be a use:: tag.  Especially
when there are works-with::bugs etc.
 
> > > "Network Monitoring"
> > > 	iterating.org proposed to map to "security::ids"; it can also be
> > > 	mapped to admin::monitoring, use::monitor, network::scanner,
> > > 	depending on cases.  Do we need a network::monitoring?
> > Well, where does bandwidth-monitoring fit?  That's the one I
> > remember having trouble tagging.
> 
> I propose (but I'd like you to review this proposal before adding it)
> works-with::network-traffic.  It fits bandwidth monitors, shapers,
> tunnelers, firewalls...

A later message mentions my old works-with::network proposal;
:network-traffic is better in that it obviously doesn't mean the
hardware or its interface configuration.
 
> > >   "E-Commerce Software"
> > >     PROPOSAL: iterating.org proposes to add web::e-commerce
> 
> $ apt-cache search commerce
> shows a number of packages to manage financial transactions and
> interface with all sorts of payment systems:
[...]
> Ok if I just file them under web::commerce at the moment?

In principle maybe it should be network::commerce, but web:: is
where people will look. 
 
> > It makes me wonder if we should have had a comms:: (?) facet instead
> > of mail::, with tags for smtp, nntp, hamradio, irc, im, voip etc.
> > Probably too late now.
> 
> I like the idea of a communication facet to encompass the current mail
> one.  I don't like 'comms' (sounds like modems) and communication is too
> long.  But once we get a name, I think the rest of the merge will follow
> quickly.

Does "communication" sound better when you consider the alternative of
"telecommunications"?

> > >     "Video Codecs" -> "video::codes"
> > That's role::shared-lib (cf "The Theora Video Compression Codec", ie
> > libtheora0).

By the way, on the topic of role::shared-lib, it looks like an
enormous number of libraries lack that tag -  a candidate for some
sort of automation?

> > I was in favour of replacing "Section: sound" with "Section:
> > multimedia" before I ever heard of debtags, so you'll hear no
> > arguments from me against (multi)media::audio, ::video, ::image,
> > ::3d... other than arguments against then adding duplicated
> > media::*:editing tags, that is. 
> 
> This would nicely fit media::codec as well.  I like the idea.
> media::streaming, too.  Would you like to plan the new media::* facet
> and the merge with sound::?

Let me move all those old ::TODO tags onto the appropriate new tags
and then I'll think about it. 
 
> > I have in the past thought about suggesting that we needed an
> > admin::recovery (or ::rescue) more than an admin::forensics;
> > "forensics" tends to be a sort of recovery + security combo.
> 
> We can split admin::forensics into admin::recovery and
> security::forensics.  Does it sound good?

Sounds about right.  The current bearers of admin::forensics are
almost all admin::recovery rather than security::forensics, with the
exception of autopsy, tct, and perhaps console-log and dumputils.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)