Tagging case studies - yes that makes sense - so then the hard node reference to the actual project (as opposed to a mention) means you could have a view of case studies showing all the modules used with direct links, browsable by tag.

So in the right sidebar of the download and extend page, you still have a list like:

Media
Government
Technology

Upon clicking media, you'd see:
-
Warner Bros. | Views, CCK, Embedded Media Field | some other tags | date posted (or whatever)
Some Record label | Audio, Panels
Photo gallery site building howto | imagefield, imagecache, lightbox

etc. etc.

The advantage there is you get lists of modules which are actually used / documented, rather than lists of modules who's authors could be bothered to tag them.

And yeah there's definitely no harm in having the vocabulary and trying it out for a while, I was just very fond of the showcase idea and didn't want it to get lost ;)

Nat



On Thu, Feb 12, 2009 at 3:11 PM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
Then instead of referencing the nodes from the case studies attaching
taxonomy terms to the references, we can tag the case studies
themselves, and just have taxonomy lists of case studies on those
links, can't we? I mean if you'd use this data from actual case
studies, then why not show the modules in context, where the usage is
actually described?

Note: IMHO we can remove the types of sites vocabulary always, if we
find it is not working well.

Gábor

On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole
<catch56@googlemail.com> wrote:
> In the redesign discussions, we'd discussed having nodereferences between
> case studies, site recipes and projects for this purpose rather than tags.
> That way, people documenting how particular types of sites are built could
> show which modules they used - as opposed to project owners saying 'I think
> this might be useful for'. You could then show showcases and site recipes
> next to modules, and modules next to showcases and site recipes in a
> structured way (and with some data munging, get aggregate data if needed).
> Was this discussed as an option?
>
> Nat
>
>