Re: Merging the FSF jobs page and GNU Herds

[Davi Leal]

Richard Stallman <address@hidden>:
>     Maybe, when the project has been finished, the worker (previously, one
>     of the applicants), could report if the job did comply with the "Free
>     Software Jobs Guidelines" ?.
>
> Feedback after the fact cannot do the job reliably.  The only way to
> do this task right is for someone who really understands to check the
> job advertisement before it is posted, and ask the company questions.

Even thus, somebody might lie. Nothing is 100% reliable. Human make
mistakes. Automatic checking, besides very much cheap in resources,
realizes 100% right what it does.

The feedback after the fact is a mechanism used by some sites. Though
we decide to use the "before the fact" check, we could offer the
"after the fact" check too. User feedback is never negligible.


* Check "before the fact"

   Disadvantages:
     - cost time and inconvenience for the job posters.
     - higher cost than the "after the fact" check.

   Advantages:
     + is more reliable than the "after the fact" check.
     + get a higher quality job offers set than the
       "after the fact" check, almost optimum.


The checks cost will be perhaps high because of the project's
worldwide scope. It could require language knowledges: Frech, Spanish,
German, English, Portuguese, etc. Should we take English as the
official support language?.


Our team will replace all the free to fill fields and will develop any
automatic check which be needed to offer the guarantee at technical
level. We do not have the human or financial resources to carry out
the "before and/or after the fact" checks. It could be great the FSF
offer such additional quality checks via volunteers or payed workers.

Anyway you choose to use the 'before' or the 'after' check on the job
offers, we will replace the free to fill qualifications and joboffer
fields. So we control what is exposed.  As you wrote: "I am not so
much worried about that. It isn't very effective recruiting if they
can't say what the real job is.". So, will be the "before/after the
fact" checks needed?.


>     You were right. So, we will update the Qualifications and JobOffer
>     forms to replace all the free fields with combo boxes, etc. So, there
>     will not be any free to fill field, so we restrict what kind of entity
>     Qualifications and what kind of JobOffers are published.
>
> That is good.  The next thing is that the people who do this
> need to be trained how to do it right.

You are already training us about keeping the technical side of the
project right.

> I think we should ask the people (just a few of them!) who will do
> this task to work under the person who runs the FSF Jobs page.  He
> will teach them the right way to do the job, and that way we will make
> sure it gets done right.

I agree. If somebody reading want to apply ...


>     > What is the criterion for registration?
>     >
>     > If the criterion is "nobody that develops proprietary software may
>     > apply", then we know that registered entities won't ever hire people
>     > for proprietary software development.  Otherwise we don't know.
>
>     Even so, they could lie. One way to minimise this harm is  make it
>     easier to applicants report wrong conducts so that the association can
>     block accounts identified by its unique IDs: email, name+address,
>     landline, mobile phone, VoIP id, etc.
>
> If each job posting will be checked by a trained person, we need not
> worry about registration.

Read below about checking each job offer  versus  checking just the
entity when they post theirs first job offers, or checking the entity
each year.


> > > But if registration is that limited, people won't have much chance
> > > of getting hired.  So I think that listing people who want work
> > > is a basic mistake. It can't do any good; it can only do harm.
> >
> > Even with only one free software contract realized via this way, it is
> > better than nothing.
> >
> > Just a proposal: The access to the contact information of the "FS
> > Qualifications search" results could be allowed only to entities
> > certified as "GNU Business Network", that is to say "nobody that
> > develops proprietary software".
>
> We still have the issue of posting people looking for jobs.

We could require a Certification to be able to access the entity
filing card. The FSF could grant such certifications.

As, initially there will not be any entity with such certification,
they will not be able to view the entity qualifications filing card
that keeps the contact information. They will be only able to view the
anonymous summarized entity listing. Perhaps users will like to be
able to view it. Maybe they will even ask for getting such
certifications. ;-)

Maybe, to optimize both the GNU Herds resources and the job poster
time, we should not check every joboffer, we instead should check the
entity, and grant they a certification, something which mean "no
develops proprietary software". As you wrote: "then we know that
registered entities won't ever hire people for proprietary software
development.".

Example of certifications:
  * FS Ethical Business
  * GNU Business Network

I think certifications are the key to optimize the management of the
Free Software job site. If an entity has not renewed its certification
or just it is not certified, we could realize the "before the fact"
check and certify it again.

I am sure free software developers would prefer work for some entity
who has the "Free Software Contributor" certification. It is not
needed that every applicant check the employer background. The FSF
trained person could grant these certifications.

Regards,
Davi