- More tagging. Too many packages are still untagged.
- Inconsistent tagging. New tags were added, so many tagged packages are incompletely tagged. For example many applications don't have a user interface specified.
- (Erich) I had the idea that people can "adopt" a keyword, looking for volunteers to review a section regularly.
- Inconsistent tags. Some features have tags, while others don't
- Tag vocabulary needs more interrelationship guidelines/rules. For instance, should data::font packages also have media::font and role::font (in which case they should be automatically implied), or should they never have them? Currently some do and some don't, which is clearly wrong.
Note to the vocabulary task force: "mail,net" is a single tag, "mail, net" are two tags.
Note to the vocabulary task force: run "debtags check" from time to time
- Weekly/daily/after commit run on the server, apply a "FIXME" tag to packages which violate policy?
- (Enrico) It could be interesting to "outsource" the first tag layout of such parts to the relative communities: for example, we could ask the GNOME people to provide the right tag vocabulary for GNOME-related qualities. I imagine they may be happy to do it (and thus have their views about their software well reflected in the Debian world), and surely they know what are the right qualities in their world.
- Maintain an upgrade checklist for the vocabulary. cvs diff can help generating it.
- Ask for someone in the i18n team to join in, to help with the design of the language dependent files with tag names and descriptions
- aren't tag names nominally part of the data structure, and thus shouldn't be translated?
Make the tree less deep, don't make subfolders if only < 10 packages are left etc.
- Show tag descriptions
- Handle "virtual" tags in the tree, such as "ui", which basically is a union of "ui::gtk", "ui::qt", "ui::ncurses" etc. (virtual tags: tags where all packages are in a subgroup)
I think current vocabulary policy says that this is a can't happen. -- MartinRudat 2006-01-24 14:30:47
- (tagcoll) (Ender) Have the related command accept a tagset, and not just a package name, as the start of a search.
Make TagCollection a template with respect to the item format (I badly need to discover how to distribute templates inside libraries!)
Thoughts on classification
- Since we're somehow similar to semantic web, have a look at what it is, how it works and how crossing that path can be useful
About navigation: user induces in the tagged collection rhyzome a structure which is specific to him, nearing categories and faring(eng:? "distancing himself from"? I couldn't think of a word that would fit. -- MartinRudat 2006-01-24 14:30:47) others. This rhyzome navigation could be an interface metaphor, also bi- or tri-dimensionally mapped.
rhizome? somehow I don't think that's the right word, do I need a math dictionary? hmm... tree? tree seems to fit...
- The structure is becoming too deep IMHO. but if you want to keep the number-of-results low you need such a deep structure.
(Javier Fernández-Sanguino Peña): Have a look at TFIDF systems (implemented in bow) to use them to find out tags. Javier says he's happy to help with problems understanding TFIDF. (link? - for a start: Term frequency inverse document frequency on Wikipedia)
mornfall asks to be able to perform searches like
(!language:: || language::it), so that he can automatically install all packages from a certain tag set, but only the ones for the current locale.
- how to we put that inline?
- The correct collection generation procedure should be:
- First apply patches and renames
- Then read data into the merger
- Then apply implications and derived tags
Make a CommandlineParserWithCommands supporting command-specific switches:
addCmdSwitch("command", <same args as add()>)
addCmdSwitch("", ..) adds a switch that gets interpreted when no valid command is found
- The option parsing should then scan until it finds the first non-option argument, and see if it's a command, then re-scan the commandline with the appropriate set of switches in effect. There's a problem in this with arguments to short switches, like "-o file": "file" could be interpreted as a command and not as an option to "-o". Could be solved by having all switches be considered when scanning for the command, or (better) by scanning once for each command until a valid match is found.
- Wouldn't it be easier and/or more consistant to make the way apt/aptitude handle options into a library and use that, rather than thinking up something new?
- (Ender) Make a "best installation candidates" option: give points to tags depending on how many packages are installed and have that tag. Then sort the non-installed packages by tag score.
- (chlunde) Don't crash when giving data about a non-existing package: it might happen, such as when using the full database on a system without non-free. Don't show the application, instead. (chlunde is working on it)
- Split non-TODO items off onto their own pages.
- Link peoples' names with their user pages.
(Hervé) "The problem is, it takes a lot of time for me to dwelve into the automake info files to find out how to add to the distclean target. Do you have some hint on where to look at?(enrico)" "CLEANFILES = ~ .~ .bak .org gmon.out core \#\# .\#* in .am files. You can add that in a include file, included by every Makefile.am... (Hervé)"