Create official tag list and add to documentation

[pauby]

After a discussion in the Gitter channel around there being no list of tags I'm raising this issue for discussion around this before creating the docuimentation.

It's been suggested that the documentation be created on the Creating Packages page.

The list of tags I'm aware (off the top of my head):

• admin - installer requires Administrator privileges (such as installing Program Files);
• trial - package is a trial version
• notsilent - package requires interaction by the user after install / uninstall (such as browser windows opening and needing to be closed manually - note that it doesn't include the installer being visible as long as there is no interaction required).

List of tags I'd like to add:

~~* licensed - package requires a license to use - this is different from trial which still runs for a period of time;~~ license tag is already recommended.

Also highlight that packages should not include the tag 'chocolatey'

Agreed Tags

The tags so far agreed on are:

• admin
• trial
• notsilent
• license

Tags Under Discussion

Package category tags still under discussion:

• productivity
• programming
• utility
• browser
• drivers
• server
• client
• addon

Other tags still under discussion:

• notUninstallable

[bcurran3]

My comments from here: https://groups.google.com/forum/#!topic/chocolatey/5Sw1CXMOrJk

I'm specifically interested (at the moment) about the subject of tags in packages. I can't really find much reference to it in the Chocolatey documentation other than basically they exist and to use them.

This is partly brought up by the Narrative Docs / Walkthroughs chocolatey/docs#342 discussion at https://github.com/chocolatey/choco/issues/1303.

I would like to recommend a standard tagging procedure.

I think all package tags should include: program name and/or acronym for such software company or developer's name (standard first initial last name format?) name of any dependency package(s) a standard classification (from a published list), i.e. productivity, programming, utility, browser, drivers, server, client, addon, etc., etc. silent or notsilent install or portable (maybe install assumed and portable required?) binary when a binary is included I think it should also be clearly defined when to use: notsilent admin trial (though it should be obvious) unofficial Hopefully the end result would be a lot more consistency, easier more productive searches, and less kick backs from moderators.

[AdmiringWorm]

I agree with having a standardized classification that needs to be used (kinda similiar to having a main group the software belongs to). I also agree with having the software name should be in th tags (especially when package name and software name differ). Not sure if I agree with having the software author in the tags though. Same thing with a binary tag, seems unneccessary.

[pauby]

I agree having the software name in the tags as long as the package name and the software differ. However we don't want to have too many tags or it's going to look a mess.

With regards to the @bcurran3 tags:

• software company or developer's name (standard first initial last name format?) - I agree with @AdmiringWorm can't really see the benefit;
• name of any dependency package(s) - what is there are 3, 4, 5 or 6? I think we need to keep the tags relevant and concise;
• a standard classification (from a published list), i.e. productivity, programming, utility, browser, drivers, server, client, addon, etc., etc. - I'd agree but there should be a limit on how many of these can be used;
• silent or notsilent - I think the pacakge should be assumed to be silent, so that tag would be unnecessary, and only marked notsilent.
• install or portable (maybe install assumed and portable required?) - that generally comes from the package name;
• binary when a binary is included - I think this is unnecessary - what would be the use of it?

I think it should also be clearly defined when to use: notsilent admin trial (though it should be obvious) unofficial

That's why this is here! :)

[AdmiringWorm]

name of any dependency package(s) - what is there are 3, 4, 5 or 6? I think we need to keep the tags relevant and concise;

I somehow missed that one, I agree the tags should be kept relevant and concise. I see no reason to have a dependency mentioned in the tags, unless the package is a addon/plugin/extension of another program.

[pauby]

I am constantly mindful of the moderation guidelines for tags:

• The tags field is not being abused - I take this to mean redundant tags as well as too many tags;

[ferventcoder]

This is a good discussion. I see no need to jump in currently.

[bcurran3]

@pauby Since you're creating the documentation, could you link us to any existing documentation please? I just searched but can't find it. I know I've seen a small blurb on it somewhere, good to review it as a starting point.

I think the documentation should include:

• definition of a tag
• purpose of a tag (used in package searches on the website? where else?), i.e. how and why are they are used
• list of standardized tags and when to use them

Actually if it's officially stated now the purpose and use of tags in the Chocolatey ecosystem, I'm going to have a lot more comments and justifications. :)

[pauby]

There isn't what you're looking for AFAIK (hence the raising of this issue). There is some reference to tags in the [Moderation Guidelines[(https://chocolatey.org/docs/moderation) and in Creating Chocolatey Packages. I'm sure somebody else will jump in with more.

At the moment we have four tags that we've agreed on:

• admin
• trial
• notsilent
• license

We also agreed on a productivity tag but I believe we should limit that to two. The productivity tags that have been mentioned are:

• productivity
• programming
• utility
• browser
• drivers
• server
• client
• addon

I think the ones in bold are quite vague and would rather have something a bit more specific. I think we should stick to a list of no more than a dozen to 15 of them. Any more and I believe it will get out of hand.

I also think that the total number of tags shoould not exceed 10 with 6 - 8 being ideal? I think a dozen is excessive.

But have said about the limits I wouldn't like to limit people. Bu I do think the limits I've suggested above give packagers plenty of scope.

[bcurran3]

Do tags show up in Search Package results on the chocolatey.org website?

The answer to this significantly determines my stance on tags.

[pauby]

I believe that searching matches on the title, description and tags. @ferventcoder would be able to confirm exactly what is matched.

[AdmiringWorm]

I think it's only id and tags (or that's what I would expect anyhow)

[pauby]

I just did a search for PDF and Ghostscript came up - the only mention of PDF is in the description. Prior to that I thoguht it was title / package name and tags.

[AdmiringWorm]

I delved into the code a little bit, from the looks of it the default search uses id, summary and description, unless the search criteria is prefixed with either id:, author: or tag:

[pauby]

If you search for 'admin' (probably the most used tag) it returns 1908 packages. If you look at WinRar, the only place the word 'admin' appears is in the tags. So it must also search those.

[AdmiringWorm]

@pauby not according to the code: https://github.com/chocolatey/chocolatey.org/blob/master/nugetgallery/Website/Services/Extensions.cs#L26-L30 https://github.com/chocolatey/chocolatey.org/blob/master/nugetgallery/Website/Services/Extensions.cs#L61-L64

[pauby]

@AdmiringWorm I can only tell you what I see. There may be another simple explanation for what I see.

[gep13]

@pauby @bcurran3 @AdmiringWorm in the search box, you can do something like the following:

tag:adobe

To search specifically only for tags that contain adode

[AdmiringWorm]

@gep13 that's kinda what I meant by

search criteria is prefixed with either id:, author: or tag:

[pauby]

@gep13 If you don't use the 'tag:' prefix, what does it search by default?

@AdmiringWorm My question is revolving around what the code says is different to what I experience, assuming what I experience is not explained by a simple ... explanation :)

[gep13]

@pauby unless I am also missing something, I would say that the code that @AdmiringWorm linked to would be what is being used. What I am not clear on is whether the search goes across all the package versions for a package. i.e. Although WinRar doesn't currently have admin in it's id, summary, or description, if it had it in an older package version, would it still appear in the search results?

[pauby]

@gep13 That's what I was looking for - a simple explanation. I will try and find a package with only a couple of previous versions I can go through and come back. And maybe my inquistive mind will be satisfied :)

[pauby]

I just searched for 'admin' again and I've just gone through all the versions of Silverlight (there are only 6). Prior to the current version they didn't use the admin tag at all. None of the versions use 'admin' in the description, summary or title yet it still shows up in a search for 'admin'?

Can somebody else verify this?

[pauby]

I've also just noticed a package with teh following tag (whcih I've added to the first post so I can keep a track on them) - notUninstallable - a bit of a mouthful but maybe another tag we can consider?

[bcurran3]

So what I'm seeing here is a few problems: 1> If the development team doesn't know how tags are used on the website, the end users aren't going to know! 2> Tags need to be defined as to why they are in a package and how they are useful afterwards; which needs to be part of the documentation. (Documentation telling/suggesting things should always cover "Why?" aspect of reasoning and when appropriate cover WIIFM - What's In It For Me?)

I learned something, I never noticed the pop up over the search icon on the website showing "Search by id only with 'id:searchValue'. Search by tags with 'tags:searchValue'.

To come full circle, tags should be looked at from the end user perspective. How are they useful to an end user? IMHO I believe the Chocolatey Team sees the website package search as a way to find what you're looking for. I believe tags should be an easy way to find software that you DO NOT know you're looking for. Standardized classification/grouping tags will help this a lot.

Even though Chocolatey in concept is far from file hosting websites such as FileHippo, MajorGeeks, etc. - the display of available packages should be as easy to find as they are to install. When I go to the Chocolatey.org website, I see the same 30 packages displayed displayed over and over and over again, for years. It's very boring. When I go to these other sites, I see what's new, I get lists of what's new and/or what's popular. This gets me excited to try out new programs. Choco development is on a nice fast release schedule, but the website needs a complete overhaul to include features such as what's new to rev up users and keep them excited about Chocolatey. Hell, it would draw more users and Chocolatey.org might be able to through some ads up for revenue (Try hitting up the shareware and trial vendors that already have packages available via Chocolatey - win win!) I know there is an RSS feed and I see it in my feedly now and then... but how about a sidebar on the Chocolatey.org landing page that scrolls that RSS feed so people know about new packages?

(I went a little off-track here, so this is a little jumbled and no good segway...)

The id:Adobe is a good example. By putting the dev in as a tag, you can easily find other programs by that dev. Sometimes I "discover" a new software company and really like a product, and I want to see if they have more good stuff. Let's take NirSoft as an example, if I search on Chocolatey.org for "nirsoft" it returns 12 results. I think all but one of them are NirSoft programs. But if I search "tag:nirsoft" I get 0 results. There are other instances when I search for something where I get 300+ results but if I could use tags to limit the search to the dev, I'd be able to find what I want without having to click next and load 20 more pages. There are no perfect examples of this because the tags aren't used consistently. But as a pseudo-good example if I search for "microsoft" I get 583 results but if I search "tag:microsoft" I only get 259 - helps a lot in finding that Microsoft program I'm looking for. I actually try to search by development house a lot when the program I am trying to find is described too generically causing a ton of noise hits.

---

Agreed Tags

The tags so far agreed on are:

admin trial notsilent license Tags Under Discussion

Package category tags still under discussion:

productivity programming utility browser drivers server client addon Other tags still under discussion:

notUninstallable

admin tag - I really hate this tag. I have it default in all my templates. To me it seems that MOST packages INSTALL a program and thus require admin privileges and the tag. I tend to think exception based (and am interrupt driven), so I think the tag is useless (running with the notion that tags are only good for searches) as anyone with admin rights on their computer isn't going to pay attention to it as it's meaningless to them. I think an opposite to admin tag is much more uself. Something like "noadmin" or "noadminrights" is much more useful to an end user who has Chocolatey installed on a locked down corporate machine. If I was such a user and found (made up scenario) Tetris available to download onto my machine and it didn't require admin rights for me to get and waste time.....I'd be looking for other programs that I could get that also didn't require admin rights - How would I search for that now? I don't think I could, but it would be nice if I could simply search "tag:noadminrights." Running with this example, if the program was written in Java, I might start searching for more programs written in Java and search for java. If runtimes/dependencies are required in tags, I'd easily be able to find more Java programs that I'd be able to run.

server tag - might need some definition or possibly two tags - Is it a program that only runs on server OSes? Or is it a server function program that could run on any Windows OS?

Honestly, I think we're trying to reinvent the wheel here. IMHO I think some research should be done by reviewing popular download sites and seeing how they use the tags as well as what popular tags they use. It's not about copying other people's ideas, it's about presenting the information to Chocolatey users in a format that they already know and expect.

---

[dragonwolf83]

I think some concepts shouldn't be tags. It's very easy to abuse this concept where a better solution is to make more of the meta-data on software packages searchable instead of making it all "tags".

For example, software company and author are critical for searching as @bcurran3's use cases show. However, that is not a tag. That is distinct information that should be included in the meta-data and made available to search. Software Name, Package Name, Version, Last Update, Maintainers are all pieces of this meta-data.

One of the biggest problems for me is that I can't effectively search Software Name. I want to find all versions of SQL Server or Visual Studio and I get tons of stuff that is neither of those things. I try to cheat with tags but not all of them use the same tags nor should they. If I use tags for those things, I'm being redundant and wasting space for it. It devalues the usefulness of tags. Many parts of the meta-data is already there and just needs to be made searchable by that field alone. Then, if anything is missing in that meta-data that people are abusing tags for, could be made into a distinct field and made searchable as well.

Where tags are most useful is specifying multiple labels to something that can't be easily put into one category or definition. This works creates searchable "keywords" that you might want applied when one word doesn't do it justice. As someone who still puts application into a folder structure by category, I can tell you that it's hard to classify some apps by one category. Tags are a solution to that problem. It's usefulness though will only be as good as a developer/maintainer's ability to anticipate how their use base will think of their software. It might be something that needs to be done by the community, machine learning, or job.

[bcurran3]

I can agree pretty much with @dragonwolf83 said.

I think a clear definition of the purpose and use of tags needs to be established as precedent before a decision on what tags to use is made.

If tags are only used by Chocolatey.org search and search can be made more granular without the use of tags, it seems tags might not be useful at all in most cases but necessary for some exceptions or basic categorization.

Tags use should be useful.

[bcurran3]

notUninstallable - a bit of a mouthful but maybe another tag we can consider?

Another consideration: should tags be dictated as being lowercase only?

I realize that searches/search results should be case insensitive, but I can foresee the possibility of displaying a list of used tags, or tag cloud, where duplicates would be shown due to the same tags with differing upper/lowercase spellings - might be wise to prevent it right from the "start."

Let's make Chocolatey tags useful! (snicker)

[ferventcoder]

1> If the development team doesn't know how tags are used on the website, the end users aren't going to know!

The development team knows. Search by default is on id, title, description, tags (and maybe some other text field). There are weighting that go into this as well.

You use id:, etc to limit the search to just those fields.

[ferventcoder]

Chocolatey.org might be able to through some ads up for revenue

No. No ads. Ever.

[ferventcoder]

admin tag - I really hate this tag. [..snip...] I think an opposite to admin tag is much more uself. Something like "noadmin" or "noadminrights" is much more useful to an end user who has Chocolatey installed on a locked down corporate machine.

I actually think I agree with this more and more. I would much rather see a "portable" tag if the package doesn't have ".portable" as part of its name.