FS#45447 - [AUR 4] document/standardize keywords
Attached to Project:
AUR web interface
Opened by Johannes Dewender (JonnyJD) - Wednesday, 24 June 2015, 09:08 GMT
Last edited by Lukas Fleischer (lfleischer) - Saturday, 12 December 2015, 23:50 GMT
Opened by Johannes Dewender (JonnyJD) - Wednesday, 24 June 2015, 09:08 GMT
Last edited by Lukas Fleischer (lfleischer) - Saturday, 12 December 2015, 23:50 GMT
|
Details
With
https://projects.archlinux.org/aurweb.git/commit/?id=5fb7a74e23b2059ec0c1acb72d8d804adbf05c52
Categories were removed and keyword support was added (without copying categories to keywords). I might have missed that but I have seen no announcement and no documentation about Keywords. With categories we only had a certain set to choose from and this was fairly self-explanatory. With keywords you can do lots of things and if everybody does something different, then there isn't much purpose. So we do need some documentation and maybe a list of keywords currently in use. What exactly is the intent of keywords anyways? The intial commit indicates they should be "better categories", but you can't filter search results with results only having a certain keyword. With https://projects.archlinux.org/aurweb.git/commit/?id=d852da79e4c3de66552bc216a76bdfa40bc1e0bd Keywords look like "tags" and are linked to a "normal" search with the tag/keyword. Not only packages having the keyword are found, but also packages having the "keyword" in the name or description. This indicates this should neither be a category or tag, but a "search hint". In that case linking to the search is of no use. So we should find out what we want to do with keywords, implement and document such a usage. 1) tag or category that can be used as a filter 2) search hint 3) ? Example: Having the keyword "lib32" for the package "lib32-ffmpeg" is fine as a category or tag, but nonsense as a search hint. |
This task depends upon
Closed by Lukas Fleischer (lfleischer)
Saturday, 12 December 2015, 23:50 GMT
Reason for closing: Deferred
Saturday, 12 December 2015, 23:50 GMT
Reason for closing: Deferred
They were created as a replacement for categories, but like I said: currently they are not a good replacement.
maybe implementing the category field again and this time use the same categories as these 3 project and add a "none" for first uploaded.
Users could short by category and if a package have "none" they could sugest one of the fitting existing categories.
Previously categories were used, even if the option were porly selected, but not no one is using them and with a default blank is less likely to be used.