[Osmf-talk] Framework for the foundation's hiring practices

[Andy Allan]

On Wed, 6 May 2020 at 22:26, Tobias Knerr <osm at tobias-knerr.de> wrote:

> We know there are many issues with hiring people, but we hope that we
> can install meaningful guardrails against the risks. Your input will
> help us devise a strategy that makes sure we define the right jobs and
> hire the right people for them.

I'm in general happy with the idea of OSMF hiring people to work on
OSM projects. This won't be much of a surprise for those of you with a
long enough memory to know that I was the first person to be
contracted by OSMF to write software for the community, way back in
2012. I mention this to show that it has been done before, and it
worked fine, and given due care it can work well again in the future.

My main concerns are focussed on people being hired to work on our
software projects, namely:

1) Care should be taken not to swamp the existing volunteers. It's
easy to hire just one full time equivalent and for that to be a 10 or
20-fold increase in work done on that project. It runs the risk of
overloading the existing maintainers with discussions and pull
requests to review, and of detracting from other unrelated but still
important work. So I would recommend being cautious at first, no more
than doubling the existing work (could be 1-2 days per fortnight for
many projects) until everyone is happy that things are running
smoothly.

2) In all projects you can either add new features, or do other work
that makes adding new features easier in future. The latter covers all
manner of things from setting up CI, to writing developer
documentation, from onboarding new volunteers, to refactoring and
other maintenance tasks. But the first one is what people are normally
hired to do, even though the latter is usually better long-term value.
I would like to see at least half the time spent by paid contributors
explicitly falling into the second category, ideally with existing
maintainers steering which aspects of this are most wanted.

Other than this, I would encourage the OSMF to hire carefully at
first, and learn what works, and to iterate.

Thanks,
Andy