Categorize Gems Listing

[David L. Collison]

It would be nice if you would provide an interface that has the gems
categorized. When I'm looking for particular functionality, I
shouldn't have to scroll through all the gems on the site to locate
something that may fit.

[Jeremy Hinegardner]

You mean something like http://ruby-toolbox.com/ ?

-jeremy

--
========================================================================
Jeremy Hinegardner jer...@hinegardner.org

[Nick Quaranto]

Tags/categories seem like a great idea, and I would love to integrate with ruby-toolbox if at all possible. It would just be a boatload of work to run through all 13,000+ gems and categorize them. Maybe once we get metadata in the gemspecs we can finally do this.

-Nick

[David Chelimsky]

Is there a move to add metadata to gemspecs? And if so, is it a free-for-all or is there a plan to devise some sort of guideline taxonomy?

[John Barnette]

On Jun 23, 2010, at 3:07 PM, David Chelimsky wrote:

Is there a move to add metadata to gemspecs? And if so, is it a free-for-all or is there a plan to devise some sort of guideline taxonomy?

I've been wanting for a while (I have branches that are mostly implemented, even) to add arbitrary metadata to the gemspec. Just a simple hash, strings for keys, and simple scalars for values. No official keys, just do a free-for-all and see what usage pops out. I haven't had time to finish it, and anything that a) changes serialization and b) requires a major spec version jump in RubyGems is worth moving slowly on. :)

With regard to tags and categories, they sound neat at first, but I think they're pointless. Either we spend significant time and effort curating a taxonomy and bikeshedding about what goes where, or everybody tags/categorizes their gems differently and the whole thing looks half-assed.

The OP was unhappy about scrolling through all the gems on the site, apparently, but I'm curious why the current search engine didn't help narrow things down to a useful set. It certainly does for me.

[Chad Woolley]

On Thu, Jun 24, 2010 at 8:43 AM, John Barnette <jbar...@gmail.com> wrote:
> With regard to tags and categories, they sound neat at first, but I think
> they're pointless. Either we spend significant time and effort curating a
> taxonomy and bikeshedding about what goes where, or everybody
> tags/categorizes their gems differently and the whole thing looks
> half-assed.

Doesn't rubyforge already have a taxonomy, and some existing data
(albeit for old gems)?

-- Chad

[Tom Copeland]

Yup, although it's a per-project categorization, which is not necessarily per-gem... although they're probably the same in 90% of the cases...

Yours,

Tom

[Luis Lavena]

On Jun 24, 12:18 pm, Tom Copeland <t...@infoether.com> wrote:
> On Jun 24, 2010, at 11:59 AM, Chad Woolley wrote:
>

> > On Thu, Jun 24, 2010 at 8:43 AM, John Barnette <jbarne...@gmail.com> wrote:
> >> With regard to tags and categories, they sound neat at first, but I think
> >> they're pointless. Either we spend significant time and effort curating a
> >> taxonomy and bikeshedding about what goes where, or everybody
> >> tags/categorizes their gems differently and the whole thing looks
> >> half-assed.
>
> > Doesn't rubyforge already have a taxonomy, and some existing data
> > (albeit for old gems)?
>
> Yup, although it's a per-project categorization, which is not necessarily per-gem... although they're probably the same in 90% of the cases...
>

That could ease the tagging of 13K gems.

At least populate that in rubygems.org and then allow gem owners/
contributors to adjust the categories.

I think that sounds feasible?

--
Luis Lavena

[John Barnette]

On Jun 24, 2010, at 11:38 AM, Luis Lavena wrote:
> That could ease the tagging of 13K gems.
>
> At least populate that in rubygems.org and then allow gem owners/
> contributors to adjust the categories.
>
> I think that sounds feasible?

I'd really like to make sure we know what problem this is solving before anybody spends time on it. How is this better than search?

~ j.

[Anuj Dutta]

IMHO, categories will enable to describe a gem better. Sometimes, gem name is not an apt description of the gem's functionality and with categories one can easily find such a gem.

Anuj
@andhapp

------------------

[David L. Collison]

You last sentence identifies the true issue. Yes - 90% of the time I
can come in to the site, key in the search terms that I'm looking for,
identify the gem and I'm on my way. However, sometimes I like to
browse these sites and get different ideas on how to solve problems or
identify useful gems that might assist me down the road. Simply
scrolling through all the gems on the site doesn't lend itself to this
type of browsing/learning. I believe that by creating and utilizing
categories - yes it would be a pain to setup - but I believe it would
benefit not only myself but other developers.

[Gabriel Horner]

> I'd really like to make sure we know what problem this is solving before anybody spends time on it. How is this better than search?

Tags are mainly used to let users create arbitrary lists of items.
Creating lists of gems has some overlap with search but it also
provides new functionality. By having a tagged list, we can point to a
specific group of gems with one url. This is pretty helpful when
shopping for new gems. Sure we could do this with Delicious but we
wouldn't be able to also display gem-specific attributes i.e.
description, downloads, authors in one page. ruby-toolbox is a start
in the right direction but the rubygems taxonomy should be in the
hands of the community, not one individual.

As for gem taxonomy, I don't think it will be that hard. We already
have a good start with ruby-toolbox and rubyforge categories. Some
ideas on how this could work:

* Tags should be driven by gem authors in their gemspecs. We may make
an exception to merge a local list of gems and tags for popular gems
whose authors are lazy, uninterested, hard to contact, etc.

* Any tag, official or not, would exist at /tag/:tag i.e.
http://rubygems.org/tag/twitter . A tag page would simply list gems
with relevant attributes to compare gems.

* Tags would have a landing page at /tags. We can avoid worrying about
tags looking half-assed by having this page only list official tags.
If users want to be affiliated with the right tag, they'll do it. If
not, their loss.

* To make the taxonomy flexible, we should have a suggestions form. It
would be good to have an explicit policy telling the user we only add
tags if they're being used by X number of gems.

I'll volunteer to help with curating tags.

@andhapp: If you want to describe gems better, use the gemspec
description and summary attributes.

Gabriel