Implement Community Tags for d.o projects

So ... are you constructively suggesting a new category to put these three results in?

Or are you just having a rant because you found searching too difficult?

it looks like there are a handful of project management/time tracking projects out there, so adding a category for this case may make sense. But adding a category for everyones search terms does not.

If a project description written by the developers is not clear to you, perhaps you could ask in their queue to provide a screenshot or link to a demo site. Many projects are a bit opaque like that.

You mean the tags saying:

Address field for CCK : [Content · Content Construction Kit (CCK) · Modules]

?

I guess that tells us that it's a "Module" called "Address field" that manages "Content" and works with the "Content Construction Kit (CCK)".

With them we can get to all modules that deal with cck or content. Each of them pretty big lists, I'm sure, but it filters the list down from 2000 to 50 or so?

What are you suggesting better taxonomy categorizations for that module would be? What is the missing mojo that you think would improve it?

Drupal strength IS in it's use of taxonomy, so we can surely draw that out a bit better.

The current set:

Projects

... is looking a bit crowded.
I guess "Address field" could probably be tagged with "Location" - that's up to the maintainer.
I don't know that we need a "Geo" category as well though - and I wasn't aware that address field did do geocoding. ... which I guess is your point :-)

We have both Media and File management OK...
I'm guessing that you couldn't find Project Management in that broad list because there were less than a dozen out there, and time tracking half that. The results so far most have upwards of a hundred items...

Sooo...
It may be time to suggest adding a heirarchy and a new layer of terms into our taxonomy. It sure is not very useful to have upwards of a hundred results in such broad categories.
Worth looking at ... but I think this therefore comes into all the other huge d.o. redesign threads about increasing findability of modules? Maybe you can raise the suggestion there.

perhaps it would be good to have a free-tagging taxonomy for general info about tags? I know these can get messy, but they might help some people with searching, and show related modules that don't otherwise appear to be linked

It's also true that projects are not correctly tagged by the authors; I found a filter module listed under Views, which was not an exact tag for the module.

I mean that categories can be changed, but then there is still the problem of using the correct category for a project. Against that, there is nothing you can do.

?
It's true that I already know the terminology, but from that page of CCK modules, all but one were pretty well-described (I thought) in their first sentence.
My eyes went fuzzy on "CCK Taxonomy Super Select Ultra" but the rest of them were described in English.

- allow you to create premium fields: fields that only certain users can have on their nodes.
- Define which cck fields should be able to keep private.
- This module provides a CCK field for redirecting a user to a new URI.
- This module hides specific content types and fields from CCK.
- This module adds a CCK table field type that lets you add a table display to any content type without having to manually enter HTML.
..

... OK, you have to already know what "CCK", "Content Type" and "Field" mean, but it's not true to say that the descriptions don't say what they do.

But yes, the tags are pretty vague. What could a better intuative tag be to describe a module that "hides specific content types and fields from CCK."?

Categories are thought to group projects that have something in common, but you cannot come out with too much categories, or you still have the problem of understanding which is the category you should look for. If there would be so much categories that each category would contain just a single project, it would be a problem.

It's not fault of the category system, if some types of projects are more developed than others; CCK modules, in example, are alot because CCK is a system to have additional fields without to create a custom module just to handle a custom content type that would be used only in a particular case.

I know you are not advocating to arrive to have a category with a single project listed. What I meant is that you could have the problem of finding the module you need of even after the number of categories is increased; paradoxally, having too much categories create the same problem than having too few categories.

The problem is not on the number of categories, but on having the correct categories. Which criterion to use to decide when the categories are correct is the hard part, I guess.

This is how the module categorization appears to be for the prototype: http://infrastructure.drupal.org/drupal.org-style-guide/prototype/module...

• Categories (two types? or two views? Check boxes in #content but links in #sidebar)
• Site type
• tags

I would guess that "Categories" would be editorially constructed, while the tags would allow free tagging by the author. Hopefully, the links in this view are for faceted searching to allow a user to drill down to the type of modules they're looking for.

Can this structure meet the requirements of this issue?

First, those 6 editorial-driven categories remain far too simplistic and will return too many modules.

I didn't presume that the categories would be limited to those displayed 8. The "more categories" link suggested to me that the page would display much more than an additional 4 entries.

Also, keep in mind the value of a community movement to provide a more consistent tagging structure. We don't have such a movement at the moment because this site isn't set up yet to navigate in that manner. I feel confident that the high quality modules would all end up being tagged in a consistent manner. Tagging is marketing... it is beneficial for module authors to tag consistently.

The risk of taxonomy misuse already exists with the actual project vocabulary; nothing stops you by tagging your module with "Views" when it's not related with Views in anyway.

@ceardach: "...keep in mind the value of a community movement to provide a more consistent tagging structure." To be community-managed, the community must be able to manage the tags. That means more than just adding tags, which is apparently the current limit.

The community does not have to have the power to go in and edit the tags of projects in order to be influential upon how the tags are structured. All it would require is creating consistency, and notifying outliers about "the way things are done." If a module developer chooses to not properly categorize their module, they are likely not good module developers.

Mark Bolton has proposed a categorization system, which we're on the path to follow. If you disagree with it, propose a constructive modification to that system.

Aren: "to be community-managed, the community must be able to manage the tags."

Last.fm lets all users manage tags for a song/band/album on a per-user basis, and then the tags that are the most used are listed first. It works really well. I think this would require a fairly massive taxonomy overhaul though.

The problem is that in Drupal, without any third-party modules, the user interface for the taxonomy terms is limited; or you have a vocabulary where all terms are tags (and the users are free to use any term they like better), or you have a vocabulary where the user can select one or more terms from a list.

@Aren Cambre: Please propose a solution we can actually act upon.

@naught101: I think such a system would be good, but it requires a contributed module. Is it possible for us to get such a module created within the next two months?

I don't think it would be a massive taxonomy overhaul at all. Add a tab to a node for user contributed taxonomy. A new table would store [UID, NID, TID]. New terms created by the user would be added to the vocabulary. When configured "n" number of users agree on a term, node is tagged with that term. Users can change their tagging, and if the removal of a tag lowers it under the threshold, then the node is untagged.

I would prefer to maximize the tools we have before adding more work for us. But if someone can get such a module done, then that's great. In the mean time, what are possible solutions to maximize the taxonomy system and our community to get the job done?

@Aren: Would Unitag meet your requirements?

Community Tags is probably more appropriate.

This should probably be moved to redesign.

Agree

I'm very sure this was already planned in the redesign. See http://infrastructure.drupal.org/drupal.org-style-guide/prototype/module...

Marked #512620: Freetagging for themes? and #509056: Create a free tags vocabulary for projects as duplicate of this issue.

Well, I don't know how I managed to miss this issue when I searched before filing mine. I searched on "freetagging". So here it is a few more times for good measure for anyone else searching: freetagging freetagging freetagging :)

Michelle

The term used for lastfm-style tagging is Folksonomy. It's probably a more appropriate term, since it's bit different to the drupal-style taxonomy: ie. drupal taxonomy simply allows you to add terms per-node, where as a folksonomy allows per-node-per-user terms, which are then sorted according to popularity.

What module best meets the needs for this issue? If that module does not meet all needs of the issue, what are they?

• Unitag
• Community Tags

Community tags by far since it has the most community-supported. But I'm fairly sure that it will take a bit of cleanup and optimization to be able to be used on drupal.org.

Basing on #533802: Tags are lost after node preview if read-only mode is enabled, I would say that is better Community Tags.
Of course, the issue could be resolved before the module is adopted on Drupal.org; still, basing on the number of users who is using Community Tags, I think this module is better (the more people use a module, the easier a issue is found).

Unitag has no way of ranking user-supplied tags, because it uses the vanilla taxonomy system. Because Community Tags saves tags per-user/per-node, it can automatically rank tags by popularity (which implies importance/relevance). That said, it requires more database hits.

It also allows users to tag content without having to edit it (tags don't affect content categories).

I tried both the modules, and I find Community Tags more interesting.
Could Community tags create a conflict with Comment Alter?

Linking this from the Redesign project #661566: Meta issue for Drupal.org webmaster project because this issue was tagged 'drupal.org redesign'

Does this mean that all the new issues about Drupal redesign should be open in that issue queue?

Hi kiamlaluno, yes, any new redesign issues should go into the new project, unless they are related to the redesigned theme, Blue Cheese, then put them here http://drupal.org/project/bluecheese

Once issues have been resolved for the redesign, they can always be changed into another project If needed.

Thanks for the reply, lisarex. If find a redesign issue, should I move it to the neww issue queue?

Can we at least start by opening a free-tagging vocabulary up to project owners/editors only and not all users? This is more and more necessary as we're seeing more issues like #1128116: Remove "Drupal Commerce" category from project taxonomy where it would be more appropriate to have modules that integrate with Drupal Commerce use a tag rather than a full-blown module category.

I'm really not keen on this idea at all.

Even if restricted to project owners, we are bound to get heaps of duplication and crosstalk as people tag things in different ways.

I do see the need for grouping modules into families around central key modules, in a way that is finer and more specific (and possibly sometimes orthogonal) to the current module categories. So things like Ubercart, Commerce, Views, Context, Media, etc... But I think it would be better to make that a fixed vocabulary that we add to via the issue queue.

I think that's more of a pain. I think we can trust module authors a bit more to use it more responsibly that normal users. The proper solution is to integrate with the .info files in modules and display that info, but I'd like to get some kind of solution for 'now', although I know lisarex will probably hate me for that.

Another hard-defined taxonomy will just have the same problems as our current module taxonomy.

> Another hard-defined taxonomy will just have the same problems as our current module taxonomy.

Will it? I'm not sure what we're saying the current problem is.
Looking at the Drupal Commerce issue it looks like we need finer granularity, while still keeping the Categories vocabulary broad-sweeping.

The only problem I can see if a second 'Module family' vocabulary is fixed is of bottlenecks to new terms in the issue queue -- granted that's a pain. But with free tagging we're surely going to get issues to merge tags, rename them, etc, and there's going to be just as much of a bottleneck while things are discussed.

If it must be tagging, at the very least I think there should be a group on gdo to discuss taxonomy. And even then, I just see this turning into a big mess :/

@Dave Reid, I could never hate you :)

Go with the solution that enables you to do your jobs better.

Agree with davereid, if only because I want to see this happen, and a small step is better than no step. I don't see the point of having two fixed-term vocabs. The current mix of use/supermodule seems to work fine, and wouldn't particularly benefit from being split in two (wouldn't make a difference to site users, just make it harder for admins to see what's going on).

It might be good to make the open vocab more "hidden" somehow, ie. not display on project pages, or only display if the term contains above a certain threshold of projects (I don't know of any particular projects that can do this). That might reduce the messiness.

Lack of standardisation is not a problem, I think: eventually, the more popular tags will organically become more used, because doing so will be the best way to promote projects. The most popular and useful tags could be eventuall moved into the main vocabulary (taxonomy_manager can do this relatively easily in d6). The benefit of community_tags.module is that the tags are updated more frequently, and will more quickly become useful.

Moving this to the appropriate queue. Also, this probably needs some kind of performance review from someone in the know.

Closing old issues. Please re-open if needed.

Too bad this never got off the ground ... This would still be very useful.

A partial alternative is in #1323826: Make it easier to identify and discover ecosystem modules, but that's also stale.