Re: Skills classification -- proposal

[GNU Herds work team]

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

Richard Stallman wrote:
> > 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.
>
> That seems like a mistake.  If users can write _anything_ then it
> takes human intelligence to understand what they say.

When some entity add an offer, the Human Resources selection process could 
follow the below steps:

  1. The webapp automatically filter and/or sort applicants according to
     the match with the skills exposed at the offer.  (optional)
  2. The HH.RR. staff read some applications
  3. The HH.RR. staff choose the best applicants
  4. The HH.RR. staff get a first contact, via phone or email, etc.
  5. The HH.RR. staff take a second contact, face to face. Maybe via
     video conferencing.
  6. The HH.RR: staff realize some tests, etc.  (optional)
  7. The HH.RR. staff fill the vacancy with the best candidates. (optional)


About the webapp, skills classification will not be done automatically, but by 
hand, by the Skills administrators.

We have just to classify the new skills added by users, and that is even 
optional. There are a lot of skills already classified at the data base. When 
new users fill his resume more than 60% of their skills are automatically 
classified due to users use to fill the same skills: HTML, C, etc.

  We could even not classify odd skills entries. Of course classifying an 
skill takes human intelligence, but only for the new skills and only the 
first time they are filled.  Note that when we, as gnuherds developers, 
decide to add or not a new skill to a ComboBox it is needed human 
intelligence too.

The difference is that now the webapp user is who transparently _propose_ 
the 'addition' of such skills to the data base.  Users propose the skill 
addition which they want to use in their resumes. What the webapp 
administrators have to do is just classify it. That task can be realized by 
the webapp Skills administrators. We can carry out this task at least 
initially.


Users use to fill common skills, which are already added and classified, as 
C++, C, PHP, etc.  It is just that they can propose the addion of any new 
one.  That is good for the project and for the users.  It is as realizing a 
survey to fill the supported skills, according to the webapp users needs.

The database has lots of skills already loaded, and we think that at the end 
it will be unusual that users write a skill which is not already added and 
classified.  So raising a new pending-to-classify skill will be unusual at 
the end.  The webapp will follow a guided 'learning' process up to it be 
almost self-sufficient.


The fix list of skills is not an actual design alternative due to it is very 
hard to use for the webapp users, and it is not flexible.

We have already tried to offer to the user fixed lists of skills to choose 
from. The current solution is a lot better for the user, for the webapp 
administrators and for the project. It is working rightly. If some problem 
arise the next year we will fix it, but we must not try to fix a problem 
which does not exists.


> > 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.
>
> That is basically impossible, right?  You would need to understand
> their words.
>
> You could perhaps detect that it mentions the name of a non-free
> program.  For that you'd need a list of all non-free programs.  There
> must be thousands of those!

That will be done by hand by the Skills administrators.

We will classify only on demand, when they are actually written by the first 
user.  So we will not need to add all non-free programs neither all free 
programs.  That is to say, if any user fill "Rational Rose" the webapp will 
never add it to its data base.  If nobody demand the "Vim" skill, it will be 
neither added to the skills data base.

As you said, it is not usual that users add odd skills entries, so there will 
be not too much work for the Skills administrators.  Besides, as the skills 
data base grow it will be unusual that users insert a skill which is not 
already added and classified.  Do not worry, we will do the Skills 
administration task, at least the first months. We have almost ready to 
commit the new skills administration page, which allows realize that task 
easily.


> > > What does "free documentation skill" mean?
> >
> > Say a user fill 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.
>
> I think that is confused.  "I wrote the GNU Emacs Manual" is not a
> skill, it is an accomplishment.  If you ask for "accomplishments",
> people will give things like "I wrote the GNU Emacs Manual".  If you
> ask for skills, they will say general things like "Writing manuals".
> Or perhaps "Using MS Word".

That was just an extreme example.  You are right, people use to fill what the 
form ask for.  So, there will be not too much work for the Skills 
administrators. All users will fill the same skills.

The current design is working very well.

> You don't have to worry about how to tag something
> that people are unlikely to give as a "skill".

Unlikely but possible.  We do not lose nothing by defining a complete and 
coherent category. We could use it or not, but anyway it is good have it at 
hand.

Please, let us know any disagreement.

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

iD8DBQFHVImiX9bt9qIT3xkRAisxAKCIrqAK58UkMq84G6KqyiTASUkDWQCfVrv/
U0J0sU7dgQIwwwQnq/lBD2U=
=KAvE
-----END PGP SIGNATURE-----