Hiring Targeted Developers ...

Board Discuss
#1

Hi everyone,

  Let me try to provide a simpler proposal that combines several
ideas from the thread and focuses on clarifying the management
aspect. Hopefully as an E-mail it is easier to interact with the
content.

* Rationale

  A selection of points from Paolo's discussion on the list:

  * As shown by Italo's slides at FOSDEM again and by others,
    TDF is not contributing code as much as it could

  * Members of the ecosystem and others also suggested that we
    should spend more money to grow development

  * certain topics such Target Areas as accessibility and
    RTL/CTL can be harder to taken care of by volunteers without
    help, and are not always addressed by the ecosystem

  * We need to build up skills and development capabilities to
    speed up innovation and diversify the LibreOffice community.

* So I propose:

* Hire a Targeted Developer, with primary focus on mentoring

  Why is it important to major on mentoring: TDF has an
educational mission -and- we want to grow and diversify our volunteer
community. Training existing and new contributors in specific areas
can accelerate our mission, grow capability in these Target Areas,
while also addressing functional gaps in LibreOffice.

  It is also expected that while the mentor is unable to
actively contribute to public and professional education for whatever
reason (eg. absence of volunteers) that they will be researching and
increasing their experience by contributing to new ways to advance the
free software and standards in their particular Target Areas.

  In addition to direct mentoring they can document related
code, publish and speak at related conferences in these spaces and
educate the public on the relevance, capabilities and mission of
LibreOffice to encourage cooperation with other organizations that
pursue, at least partially, the same goals.

* Selecting Target Areas

  The process of selecting Target Areas to apply additional
development resource to is one that is potentially highly
contentious. It is vital that we have a clear, transparent and capable
process to do this. It is important that TDF stewards its limited
resources well, and does not invest in areas that are already well
resourced, or to crowd out 3rd party funding. So:

  * Any TDF member can identify a suitable high-level Target
           Area such as RTL, complex-text, or accessibility.

  * The ESC will rank such areas as an addendum to the existing
    budget ranking process, and exceptionally during
    bootstrapping. The full ranking and votes will be published

  * The Board (who bear the ultimate decision) will select
    suitable areas for Targeted Developer(s). Such mentors to
    be in addition to existing generalised mentors.

* Day to day management

  Targeted Developer(s) (as normal dev-mentors) shall attend
the ESC call, and report on their progress weekly in the normal way.

  To maximise benefit to LibreOffice ESC members can privately
disclose any live / credible overlaps with their work in sub-areas
without having to disclose full details of potential or pending
business in this area. Such specific sub-areas will be avoided for a
time.

  The Executive Director shall direct day to day management for
the Targeted Developers to ensure they effectively focus on the
Target Areas.

* Bootstrapping

  The ESC should be encouraged to identify and rank some
suitable Target Areas rapidly. This shall allow the Board to agree
them, and a hiring process with skills targeted at these areas to
commence post haste.

  TDF should start with hiring a single Targeted Developer
initially, with the option to expand this to two if multiple suitable
candidates present at the interview stage - and evaluate the process
after a year.

  It is expected that it will be hard to find a senior developer
with all the needed skills from the day one. The tendering group
inside the Board should tender for a suitable amount of mentoring
hours from several senior certified developers, to help to get the
newly hired Targeted Developer(s) up-to-speed.

#2

If mentoring is put in the center, it seriously limits the pool of applicants. Most devs who could apply will simply skip it. We know this from the experience in 2017-2021 and comments that C++ devs made when the mentoring position was advertised.

Ilmari

#3

Hi Ilmari,

Ilmari Lauhakangas píše v Po 23. 05. 2022 v 20:08 +0300:

> * Hire a Targeted Developer, with primary focus on mentoring

If mentoring is put in the center, it seriously limits the pool of
applicants. Most devs who could apply will simply skip it. We know
this
from the experience in 2017-2021 and comments that C++ devs made
when
the mentoring position was advertised.

I am afraid it is not clear from your message - can you please clarify
if you are dismissing the proposal as a whole, or only the name of the
role? Would a "Hire a Targeted Developer" work for you?

Thank you in advance!

All the best,
Kendy

#4

I'm thinking of what will be written in the job posting. If the title contains "mentor" and mentoring will be central in the job description, it will scare devs away. Whatever the decision about the role definition will be in the end, it's good to keep in mind the learning experiences we got in hiring.

Ilmari

#5

Hi Ilmari, all,

Ilmari Lauhakangas wrote:

I'm thinking of what will be written in the job posting. If the
title contains "mentor" and mentoring will be central in the job
description, it will scare devs away.

Yeah, I agree that past job postings were perhaps over-specific there.

The documents under discussion are our internal process- and
requirement sheet. For the outbound message on job boards, we can
certainly tweak the wording to be audience-specific. I could imagine
putting 'senior' there would attract people who've mentored,
on-boarded and levelled-up junior developers?

Cheers,

-- Thorsten

#6

Hi everyone,

  Thanks for all the contributions here. Let me try to summarize
things and look for the common ground here:

* TDF hiring one (or two) developers

  This is a common factor - apparently, as was expressed at the
beginning of this thread - this is not that controversial.

  We both want to get new people working on some of the most
important under-loved areas in LibreOffice, and ideally quickly.

  Shrinking the proposal to a minimal set that doesn't include
controversial things seems to me the best way to get quick action. A
constructive proposal was asked for - and I provided one. Hopefully it
can attract some support & the board / TDF can move to executing on it
quickly.

* Senior developers and mentors are very similar

  I'm fairly convinced that any developer that TDF should employ
should be able to work constructively in our community - which means
good communication skills, ability to compromise, and to be able to
explain complex technical concepts to persuade other community members
around their chosen direction / solution.

  These seem to me to be nearly the same soft skills we want
from a mentor.

  Open Source development is not and should not take place in
ivory towers where developers can work without significant social
interaction with others. Indeed to become a senior (as Thorsten
suggests) lots of this collaborative behaviour is expected even in
closed projects. Software is in large part about people ultimately
(for better or worse).

  So - I think any senior software engineer would be able to do
both this job and more focused development tasks; so not a huge
divergence.

  I really think, given our mission, if we have volunteers that
are eager to work in an area, and need mentoring it would be
altogether better on every axis to get them deeper into the project
and help them succeed rather than paying to do the same thing
ourselves in isolation.

* Some areas of disagreement with Paolo:

You may notice that the difference is that I believe that the 2 new
members of the team should be managed by our mentors and our ED.

  My proposal:

  https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05723.html

  leaves that decision to the ED - they should focus on
execution: "The Executive Director shall direct day to day management
for the Targeted Developers" - if they want to do that via other
mentors - that's up to them.

Michael Meeks' prefers to have the ESC controlling the
mentor/developers

  I think this is the same mis-understanding about how the ESC
behaves as some command & control body instead of a co-operate &
persuade thing. I wrote a little about that here:

https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05667.html

  But I struggle to see how you get "controlling" out of:

  "Targeted Developer(s) (as normal dev-mentors) shall attend
   the ESC call, and report on their progress weekly in the
   normal way."

  or was it somewhere else ?

but, while I value their technical input, it's a body that is very
well represented by commercial contributors employees.

I do not think it's a wise idea to have TDF's employees being
directed/controlled by our own suppliers.

  Apart from the mis-understanding about what being present and
reporting on progress in a transparent, weekly group of peers open to
anybody means, this is extraordinary to me.

  Can you expand on your concern here ? who are "our own
suppliers?" can you define the problem there in more detail ?

  I believe my proposal retains a good balance which has served
us well over the years: of the ESC advising the board on engineering
matters, the board deciding a course of action, and the ED/staff
executing on that.

  Perhaps clarifying a counter-proposal and rationale for it
would help.

* Conclusion

  I would commend the board to getting rapidly to the point
where we can hire one to two developers (depending on applications)
who can also be mentors (ie. my proposal) - since this is the kind of
person we want in the project.

  I'd also suggest - to the points about it being hard to hire
good developers (and it really is!), that we dedicate some budget to
advertising widely. I'd also suggest that we look in and/or around
academia - where (I guess) people who are competent and like learning
and teaching tend to lurk.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.