Re: Skills classification -- proposal

[GNU Herds work team]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > You exposed the need to avoid showing to the public non-free skills. So
> > we are looking for a category to classify the skill-fields users fill.  We
> > can take this opportunity to allow to tag skills more precisely, exposing
> > for example if it is Software or Documentation:


> >     (Option 3) The more complete classification could be:
> >
> >       Initial flag
> >         * Pending to classify
> >
> >       General flags
> >         * Unknown
> >         * Abstract
> >
> >       The actual classification
> >         * Software
> >             Free Software
> >             Almost-Free Software
> >             Partially-Free Software
> >             Non-Free Software
> >
> >         * Hardware
> >
> >         * Data
> >             Free
> >             Non-Free
> >
> >         * Documentation
> >             Free
> >             Non-Free
> >
> >         * Art
> >             Non-Sharable
> >             Sharable


Richard Stallman wrote:
> I don't understand what problem this is meant to be
> the solution to.

The problems are:

1) To make it easier to the user the work with the skills form, and to make 
the skill form more flexible allowing to fill skills not yet listed at the 
data base, the ComboBox skills fields (<select><option..></select>) were 
replaced by text input fields (<input type="text">). Therefore users can 
write _anything_ in such fields.

   You asked to filter what is showed to the public (e.g. non-free software 
references).  We have to know what a skill is to be able to block it. A good 
category is needed to block or not a specific case.  For example we could 
decide block or not block skills tagged as Non-Free Documentation.

2) It is the skills section of the resume forms. However users fill anything 
in such fields! Users do not fill just software skills but also Abstract 
skills as "Web Developer", "Networks", "Licensing".

   By extension, we thought it is good idea be able to tag a skill as Art-work 
or Documentation-work. If we get such skills filled by a user we will be able 
to tag it. Just to allow a complete category. That does not mean we are 
forced to use it.


> However, shouldn't you omit these three?
>
>           * Almost-Free Software
>           * Partially-Free Software
>           * Non-Free Software

Do you mean to block too skills tagged as Almost-Free Software? Note that 
Debian is tagged so. You exposed that it was right fill a job offer in which 
you look for Debian experienced administrators to do a mass installation of 
only free packages.

On the other hand, note we will add the Trusted Entity flag this weekend. The 
web application will not block anything done by trusted entities. For example 
the webapp will publish Non-Free or Pending-to-classify skills present in 
offers and qualifications/resumes of FSF trusted accounts.


> Likewise, I don't know what this is supposed to be good for,
> but the same points apply: we should not include these three
> categories:
>
>             Almost-Free Software
>             Partially-Free Software
>             Non-Free Software
>
> What does "free documentation skill" mean?

Say a user fill as a skill as "I wrote the GNU Emacs Manual". The webapp can 
tag such 'skill' as Free Documentation to allow it be showed to the public.

> What does "non-free documentation skill" mean?

Say a user fill "I wrote the MS API Manual". The project can tag such 'skill' 
as Non-Free Documentation as a way to avoid showing it to the public, and so 
not promoting it.

> If the person is skilled in writing documentation,
> he can write free documentation or non-free documentation.
> The choice of license does not alter the work needed to
> write the manual.  So what is the point here?

If a person says he have experience at writing C++ programs we tag such 
sentence as Free Software.  However, if the person says she have written MS 
Word using C++ we tag it as Non-Free Software. That is the point.

Having at hand a Non-Free Documentation tag is handy just as a way to block 
some cases. We are not forced to use such tags, but it could be good have it 
at hand.

Some of your trusted contact could give a try to the webapp to know how it 
works.

Note all this is a proposal, and if something must be fixed we will work to 
fix it.


Richard Stallman wrote:
>        GNU Emacs Manual   | Free Documentation
>        MS internal API    | Non-Free Documentation
>
> I do not understand what you have in mind here?
> What does it mean to list "GNU Emacs Manual" as a skill?
> I cannot imagine.
>
> Does it mean that he has read the GNU Emacs Manual?  If so, the right
> way to describe that is "Knows how to edit with Emacs".  The skill
> is not about the manual, it is about Emacs.

The webapp does not list skills so the user choose from. That was not usable 
due to long lists of options.  Now the webapp just allow the user write 
anything at the skills form section. So what we expose at the "GNU Emacs 
Manual" case is the possibility that the user _references_ the GNU Emacs 
Manual at some of his skills, being he the writer (documentalist) or just the 
reader. It does not mind.


When the user fills a skill the webapp search a possible match with the skills 
already kept at the data base (following a set of rules) as a way to 
autoclassify it.

The set of rules are working very well due to users use to fill similar 
skills, as: HTML, C++, php or PHP, etc.  The bigger the data base is the 
easier will be get all skills automatically classified.

The GNU Herds data base has currently the below tagged skills:

          0  Pending

          0  Unknown
         25  Abstract

        362  Free Software
          6  Almost-Free Software
          1  Partially-Free Software
         47  Non-Free Software

         14  Hardware

          0  Free Data
          0  Non-Free Data

          0  Free Documentation
          0  Non-Free Documentation

          0  Sharable Art
          0  Non-Sharable Art


So as we are working now, we will follow working to improve the project after 
it be moved to the FSF hosts.

Best regards,
The work team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFHT0g3X9bt9qIT3xkRAn1wAJ99Jjgv49loXO53YHWqXRTDmXV/gACWO1wK
WAGKkGUY4rhHxrCTBGJ8Xw==
=MSBx
-----END PGP SIGNATURE-----