[Osmf-talk] Community consultation: plans to hire a Senior Site Reliability Engineer

[Frederik Ramm]

Hi,

On 24.07.20 12:15, Guillaume Rischard wrote:
> The board would like to consult the community on our hiring plans for
> a Senior Site Reliability Engineer.

I find the job title strange. I don't know the backstory. Is there a
particular reason you can't just hire a sysadmin? If I were a volunteer
working in current sysadmin, I would find it strange that apparently my
work is of such a standard that it needs a senior persion to make it
"reliable".

I know that in some markets job titles are important but why not say
you're looking for someone to help with sysadmin and they can then pick
what they want on the business card. If that person then chooses "Senior
Site Reliability Engineer" so be it but if you start out be saying
you're looking for someone who fits that title - would probably turn me
off if I read it.

> *Scope of work*
> 
>   * Management, installation, configuration, maintenance, and
>     improvement of infrastructure (hardware, software, network, data
>     centres…)
>   * Supporting, mentoring and enabling volunteers and eventual future
>     coworkers

Suggest to make that "possible" future coworkers, else it sounds as if
there being coworkers at some point is already a certainty.

>   * Enforcement of usage policies
>   * Interaction with users, dealing with user requests
>   * First line of answering user tickets

As a DWG member, I would like to see the above clarified so that it does
not overlap with policies enforced by DWG or user interactions/tickets
handled by DWG.

>   * Helping the Board establish long-term infrastructure plans

This used to be the remit of the OWG. Does this mean that the OWG is now
finally officially dead, and long-term infrastructure planning is a
board responsibility?

> *For example, current project ideas include:*

I find some of these "ideas" highly contentious. But you're not saying
whose ideas these are. If these are ideas that come from the current
sysadmin team, fine, they'll know what they are doing. If these are
random ideas from the board that haven't yet seen discussion with the
current sysadmin team, then including them here will make sure that the
employee you hire starts their job with "ideas" in their head that put
them on a collusion course. Don't do that. Make *very* sure that the
ideas you list here are acceptable and not some board member pipe dream.
I know how these things work, you start a wall with post-its and
everyone sticks their ideas to it and nobody dares tell the other person
that maybe their idea is a bit shite ;)

> Being already involved in OpenStreetMap as a contributor, or experience
> with other Open Source or Open Data or volunteer communities, will be
> helpful (though not required) to understand how our community works.

Drop the "though not required", the "helpful" is weak enough and if
someone applies who is not involved with anything remotely related to
OSM, you want them to explain their suitability very well.

> The sysadmin team and board are volunteers who have full-time jobs
> outside OpenStreetMap. While we don’t expect the person to hit the
> ground running, the volunteers won’t be able to communicate with the
> person all the time or help with everything. They should be able to
> self-organise and to enjoy finding out about things themselves.

If I were reading this, what would hugely boost my confidence to apply
would be if you could commit to at least a minimal onboarding process,
for example: Successful applicant will be flown to London for a week and
have in-person discussions with current admin team and their managing
board member, with a view to define work schedule for first three
months, or somesuch. I understand this is difficult and would in turn
require commitments from current sysadmins but you're masters of airy
wording so I'm sure you can figure something out ;)

> **
> *Technical requirements*
> **

I don't know if this has been passed by the current sysadmins. Again, if
yes, fine, stick with it. If no, it seems to me that, at least looking
at the current landscape, Chef (which you listed as "should") is an
absolute "must"; the OSMF is not using some beginner low-level cookbook
clickery of Chef - someone with no in-depth Chef experience will face an
extremely steep learning curve. On the other hand, the amount of Nginx
and AWS knowledge (both of which you listed under "must") required to
understand and participate in current OSMF infrastructure is low enough
that a skilled person can easily acquire these skills on the job.

> The contract would in any case be permanent, not fixed-term or temporary.

I wonder if "permanent" is the correct word here in legal-speak; surely
we don't want to sign a truly permanent contract in the everyday sense
of the word ;) perhaps "open-ended" is better?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"