headers
Ian Bicking | 1 Mar 2006 21:22
Gravatar

Adding trove categories

We want to add Cheese Shop categories for frameworks, so people can 
register things.

These are the ones we (Kevin and I) would like:

Framework :: Paste
Framework :: TurboGears
Framework :: TurboGears :: Widgets
Framework :: TruboGears :: Applications
Topic :: Internet :: WWW/HTTP :: WSGI
Topic :: Internet :: WWW/HTTP :: WSGI :: Application
Topic :: Internet :: WWW/HTTP :: WSGI :: Server
Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware

That's just the ones we want, and we have packages that could go in 
there right now.  I'm not that happy about putting WSGI under Topic :: 
..., but it's not really a "Framework" either.  Though putting it under 
framework would be okay too.

Also, I think a link to this should go in the sidebar:

   http://wiki.python.org/moin/CheeseShopDev

Some process for asking for new categories should be described on that 
page.  I think that process should be:

Python frameworks with plugins or packages that target the framework 
can get their own category.  The category should only be added *after* 
such packages exist.  Complimentary packages can link to each other 
from their descriptions, they do not need a category to link them
(Continue reading)

Permalink | Reply | 12 comments |
headers
Richard Jones | 2 Mar 2006 06:59
Picon

Re: Adding trove categories

On Thursday 02 March 2006 07:22, Ian Bicking wrote:
> We want to add Cheese Shop categories for frameworks, so people can
> register things.
>
> These are the ones we (Kevin and I) would like:
>
> Framework :: Paste
> Framework :: TurboGears
> Framework :: TurboGears :: Widgets
> Framework :: TruboGears :: Applications
> Topic :: Internet :: WWW/HTTP :: WSGI
> Topic :: Internet :: WWW/HTTP :: WSGI :: Application
> Topic :: Internet :: WWW/HTTP :: WSGI :: Server
> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware

Hurm. At the moment there's no top-level "Framework" grouping in the Trove 
stuff. I'm not sure what will happen if one is added. I (or someone else who 
possibly has more time) will need to test things out to make sure it won't 
fall about laughing.

> That's just the ones we want, and we have packages that could go in
> there right now.  I'm not that happy about putting WSGI under Topic ::
> ..., but it's not really a "Framework" either.  Though putting it under
> framework would be okay too.

Er, I assume that means you'd prefer it to be under Topic, or do you not care. 
I'd prefer that you make the call, to be honest.

Would "Topic :: Internet :: WWW/HTTP :: Framework :: ..." be too cubmersome?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ian Bicking | 2 Mar 2006 21:54
Gravatar

Re: Adding trove categories

On Mar 1, 2006, at 11:59 PM, Richard Jones wrote:
> On Thursday 02 March 2006 07:22, Ian Bicking wrote:
>> We want to add Cheese Shop categories for frameworks, so people can
>> register things.
>>
>> These are the ones we (Kevin and I) would like:
>>
>> Framework :: Paste
>> Framework :: TurboGears
>> Framework :: TurboGears :: Widgets
>> Framework :: TruboGears :: Applications
>> Topic :: Internet :: WWW/HTTP :: WSGI
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Application
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Server
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
>
> Hurm. At the moment there's no top-level "Framework" grouping in the 
> Trove
> stuff. I'm not sure what will happen if one is added. I (or someone 
> else who
> possibly has more time) will need to test things out to make sure it 
> won't
> fall about laughing.

As I remember the trove categories were a pretty simple entry in the 
database, just a flat list of strings.

>
>> That's just the ones we want, and we have packages that could go in
>> there right now.  I'm not that happy about putting WSGI under Topic ::
(Continue reading)

Permalink | Reply | 7 comments |
headers
Phillip J. Eby | 2 Mar 2006 23:57
Gravatar

Re: Adding trove categories

At 02:54 PM 3/2/2006 -0600, Ian Bicking wrote:
>Right now the trove categories don't make much sense for Python
>projects; lots of cruft, little granularity around things we actually
>care about.
>
>And "Topic :: Internet :: WWW/HTTP" is a super-lame category anyway ;)
>It should be "Topic :: Web".  But eh... really, the whole hierarchy and
>taxonomy of packages is stupid.

+1.  Flat is better than nested, and the current categories are insanely 
nested.  5 levels deep to get to the idea of "Message Boards"?  Wow.

That having been said, I'm sure the trove stuff was adopted for a very good 
reason, i.e., to avoid getting bogged down in taxonomy wars before there 
was even a working product.  :)

Now, however, that there are hundreds of projects already on a working 
system, it might be a good idea to see what categories are actually getting 
used, and consider collapsing them to a flatter hierarchy, or maybe even 
just tags.
Permalink | Reply | 5 comments |
headers
Richard Jones | 3 Mar 2006 00:17
Picon

Re: Adding trove categories

FYI, some revision ideas were rolled into this wiki page some time ago (mid 
2004):

   http://wiki.python.org/moin/RevisedPyPiCategories

Of course, that doesn't include Ian's recent "Framework" idea.

I'm busy at the moment, so can't really devote brain space to this problem. 
Perhaps next week I will be able to. As always, I'm perfectly happy for 
someone else to take on the problem as their own :)

    Richard
Permalink | Reply | 0 comments |
headers
Richard Jones | 3 Mar 2006 00:24
Picon

Re: Adding trove categories

On Friday 03 March 2006 10:14, you wrote:
> I'd go +1 for (freeform) tags.. the tags people want to use to
> describe their projects should shake out pretty quickly, and it
> prevents us from ever having to request a new topic whenever someone
> comes up with a new idea or web framework :)

No, free-form fields should be somewhere else. Propose a "keywords" field if 
you like, but I believe the description field performs this job adequately.

I work for a company that runs conferences. We have approximately 7,500 
proposals in across 10 conferences. They're all humanities-related, but in 
slightly different fields. Regardless, we now have 25,000 unique "keywords" 
that have been supplied from our free-form keywords field. Not so useful.

    Richard
Permalink | Reply | 2 comments |
headers
Bob Ippolito | 3 Mar 2006 00:14
Gravatar

Re: Adding trove categories


On Mar 2, 2006, at 2:57 PM, Phillip J. Eby wrote:

> At 02:54 PM 3/2/2006 -0600, Ian Bicking wrote:
>> Right now the trove categories don't make much sense for Python
>> projects; lots of cruft, little granularity around things we actually
>> care about.
>>
>> And "Topic :: Internet :: WWW/HTTP" is a super-lame category  
>> anyway ;)
>> It should be "Topic :: Web".  But eh... really, the whole  
>> hierarchy and
>> taxonomy of packages is stupid.
>
> +1.  Flat is better than nested, and the current categories are  
> insanely
> nested.  5 levels deep to get to the idea of "Message Boards"?  Wow.
>
> That having been said, I'm sure the trove stuff was adopted for a  
> very good
> reason, i.e., to avoid getting bogged down in taxonomy wars before  
> there
> was even a working product.  :)
>
> Now, however, that there are hundreds of projects already on a working
> system, it might be a good idea to see what categories are actually  
> getting
> used, and consider collapsing them to a flatter hierarchy, or maybe  
> even
> just tags.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bob Ippolito | 3 Mar 2006 00:32
Gravatar

Re: Adding trove categories


On Mar 2, 2006, at 3:24 PM, Richard Jones wrote:

> On Friday 03 March 2006 10:14, you wrote:
>> I'd go +1 for (freeform) tags.. the tags people want to use to
>> describe their projects should shake out pretty quickly, and it
>> prevents us from ever having to request a new topic whenever someone
>> comes up with a new idea or web framework :)
>
> No, free-form fields should be somewhere else. Propose a "keywords"  
> field if
> you like, but I believe the description field performs this job  
> adequately.
>
> I work for a company that runs conferences. We have approximately  
> 7,500
> proposals in across 10 conferences. They're all humanities-related,  
> but in
> slightly different fields. Regardless, we now have 25,000 unique  
> "keywords"
> that have been supplied from our free-form keywords field. Not so  
> useful.

So what?  If you're browsing, only show the N most popular ones.

-bob
Permalink | Reply | 0 comments |
headers
Ian Bicking | 3 Mar 2006 23:38
Gravatar

Re: Adding trove categories

Richard Jones wrote:
> On Friday 03 March 2006 10:14, you wrote:
> 
>>I'd go +1 for (freeform) tags.. the tags people want to use to
>>describe their projects should shake out pretty quickly, and it
>>prevents us from ever having to request a new topic whenever someone
>>comes up with a new idea or web framework :)
> 
> 
> No, free-form fields should be somewhere else. Propose a "keywords" field if 
> you like, but I believe the description field performs this job adequately.

There is a keywords field.  This would work okay if there was better 
abilities to query and browse that field.  I don't remember how it is 
stored in the database.

But anyway, assuming we are doing that, how should we open up 
participation?  The lack of a representative database dump makes it hard 
for other people to work on it on their local machines.  And of course 
Subversion access for some people.

--

-- 
Ian Bicking  /  ianb <at> colorstudy.com  /  http://blog.ianbicking.org
Permalink | Reply | 0 comments |
headers
Laura Creighton | 4 Mar 2006 16:47
Favicon

Re: Adding trove categories

>>  Topic :: Internet :: WWW/HTTP :: HTTP Servers
>>  Topic :: Internet :: WWW/HTTP :: Indexing/Search
>>  Topic :: Internet :: WWW/HTTP :: Site Management
>>  Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking

If at all possible, you do not want a hierarchy.  What you want is a
way to attatch meta-data to the project and search for intersections
of relevancies.

So -- CAPS (our main product) is a framework.  It is also a workflow system.
You can connect it to the internet, but you do not have to.  There is
a WWW client if you want one, we have others that aren't webbish at
all.  

The more versatile you are, the harder time you will have fitting into
a pre-existing heirarchy.  Which may be the whole reason you wrote the
thing in the first place -- you judged the functionality of existing
offerings inadequate precisely because they were limited by somebody's
heirarchical expectations, and you refused to be boxed in.

Laura
Permalink | Reply | 0 comments |

Gmane