[Product-Developers] Re: PloneSoftwareCenter / PyPI : classification coherence

[Raphael Ritz]

Tarek Ziadé wrote:

Hi Tarek,

first of all thanks for addressing this. I consider this really
a great addition and I have been playing with your branch a bit
recently.

I agree with you that we should use the Trove classifiers as
much as possible but obviously this is a challenge for the UI.

Before commenting on your specific points just a general remark
or question from my side:

  - are we sure we know what use cases we want to cover?

    plone.org and the Plone community itself is obviously
    one as PSC was developed for that purpose in the first
    place but as PSC turns out to be fairly generic (could be
    better of course, like supporting a language field OOTB)
    it could be used for other target groups as well.
    I for one am setting up a site for a specific scientific
    community that also produces and publishes code.

I guess we should be careful to keep PSC and in particular
its web UI useful even for people that find the Trove
classifiers intimidating or too limiting or simply not
fitting their use case.

I'm not saying that would be hard or we would be way off
I just want to reinforce that IMHO we should have that in mind.

Now to the details:

> Ok, here's my proposal. That's a lot of work, so I need to make sure that's
> what everyone involved agrees before I code it:
> 
> 1/ A new field is added, called Trove, that 
>    contains the flat list of classifiers

+1

> 2/ Each one one of this field become a single value that is
>    hooked to the Trove by its first discriminant:
> 

I understand this to mean the default value for the categories etc
vocabularies as you define them on the main SC instance, right?
If so, site managers would still be able to prune the list and/or
override the label shown in the UI etc.

>    Categories = 'Topic'
>    Available licenses = 'License'
>    Platforms = 'Operating System'
> 
> 3/ The Version field stays like it is, and keep by default
>    Plone versions
> 

This is a field that makes not much sense from a generic
perspective anyway, so fine with me.

> 4/ The leave of the trove branch is used to display the elements
> 
> For instance, this classification:   
>  
> Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking
> Topic :: Multimedia
> Topic :: Multimedia :: Sound/Audio :: Analysis
> License :: Nokia Open Source License (NOKOS)
> License :: OSI Approved :: Academic Free License (AFL)
> Operating System :: Microsoft :: Windows
> 
> Will end up having on the front page of PSC three categories:
> 
> Link Checking | Multimedia | Analysis
> 
> The only problem with that is that the leaves labels are not unique, for
> example:
> 
> Topic :: Desktop Environment :: K Desktop Environment (KDE) :: Themes
> Topic :: Desktop Environment :: Window Managers :: CTWM :: Themes
> 
> Would end up into a front page with two 'Themes' that does not refer
> to the same leave.
> 
> To prevent it, the front page could look like this:
> 
> Internet :: WWW/HTTP :: Site Management :: Link Checking | Multimedia |
> Multimedia :: Sound/Audio :: Analysis
> 
> But this doesn't look right... So my proposal is to compute a unique label
> for each leave, by adding the previous node for the leaves that have the
> same label, in order to have the shortest unique name.
> 

As long as it can easily be overridden manually (like indicated above)
I think it is OK to apply whatever magic we want to come up with a
sensible default.

I only think we shouldn't exclude the use case where people want to use
a completely customized way to do the thematic grouping (e.g., for my
current use case it would be rather something like
modeling platform | specific model implementation | data analysis tool | 
...) while still supporting the use of Trove classifiers where it
makes sense (license, language, platform, etc but also a more generic
categorization).

Maybe it would even be worthwhile to support the configuration
of a more explicit mapping from Trove's Topic classifiers to
PSC 'categories' - I don't know.


> 5/ The user will have to manage the trove himself, and a trove editor could
> help him a little bit.
> My proposal on this is to provide a form that contains the whole trove in a
> text area
> 

Might be a use case for the UeberSelectionWidget (usw)
https://svn.plone.org/svn/plone/plone.app.form/branches/plip201-usw/


So much from me at the moment,

	Raphael



> Regards
> Tarek
> 
>