enrico at enricozini.org
Fri Nov 17 12:10:55 CET 2006
On Fri, Sep 16, 2005 at 12:21:52PM +0100, Justin B Rye wrote:
While searching the archive for this thread with ideas on tracking tag
I noticed this message to which I still hadn't reacted.
> I'll start by documenting some "Tagging Hints And Tips" - the
Added to FAQ.
> Tag: field::linguistics
> Description: Linguistics
> Tag: hardware::storage:floppy
> Tag: hardware::input:keyboard
> Tag: hardware::scanner
> Tag: made-of::data:man
> Tag: works-with::network
> Description: Network
> (From previous thread. This could usefully be attached to
> network-capable games, remote as opposed to local login-mechanisms,
> etcetera, and see below on redundant network:: tags.)
In yesterday's thread, the tag works-with::network-traffic came out as
well. I like network-traffic more, but I can't decide if 'network'
includes something that 'network-traffic' doesn't.
> Tags that can be moved/eliminated to reduce duplication, or maybe
> just have their descriptions modified to clarify the distinction:
> admin::configuring vs use::configuring
> admin::login vs use::login
> admin::monitoring vs use::monitoring
> In each case there could be a distinction in terms of
> whether it's the sort of configuring/login/monitoring that
> requires an admin password, but it's not very clear.
> This whole facet is made of protocol:: dupes (without on the
> other hand managing to cover uucp, peer2peer etc).
> mail::imap vs protocol::imap
> mail::pop vs protocol::pop
> mail::smtp vs protocol::smtp
> The mail:: facet can afford to leave the protocol names for
> the dedicated protocol:: facet to handle.
> network::firewall vs security::firewall
> Perhaps the network:: one should be replaced by a
> "network::filters", to cover spamassassin, procmail(?),
> junkfilter, dansguardian etc as well as firewalls. Or a
> general use::filtering, but of course that would affect a
> huge number of text-filtering packages...
> network::configuration vs admin::configuring vs use::configuring
> network::scanner vs use::scanning
> If we're adding a works-with::network, these become even
> more redundant.
A reorganisation takes more time than adding a tag, and this morning I'm
trying to implement traceable tag patches, so that when someone known
and trusted does work on the web interface, it can go in directly
I'd appreciate if someone could ensure that we go back to this list.
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 307 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20061117/1f489cfa/attachment.pgp
More information about the Debtags-devel