Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs

Hi Simon,

thanks for all your considerations regarding accessibility.

The challenges are often attached to systemic issues and need extended time of LibreOffice experts to unpick the root cause before implementing the fix - even specifying them to tender takes research and pre-work as I expect you know. We've tendered these sorts of issues, and we could consider employing someone to deal with them full time, yes. However, there are also specialist elements - having accessibility devices for testing, for example. My sense is we would be better off paying an existing expert team (there are a few companies who specialise, not necessarily "the usual suspects") to take on the whole backlog for us for maybe 18 months, doing both engineering management and implementation and joining the ESC while they do. After that I'd return to the topic and reconsider the best approach in the light of that experience.

I can see pros and cons for both approaches (internal developer, tender).

In case of tendering, I think some cooperation of a11y experts and LO experts (like a company specializing on a11y + "one of the usual suspects") might even be more ideal than just an a11y-specialized company by itself, since from what I've seen so far, I suspect that some of the issues are somewhere deep down in the Writer/Calc/... stack that might take people without any previous experience with LibreOffice development quite a while to get into.

In any case, I think it would be important to also make sure that there will be a possibility to get a11y issues fixed in the future as well.
In case of a TDF developer, that should be relatively straight-forward because the developer can "just work on it".
In case of tendering, I would see a need for some kind of arrangement that will allow to hand out follow-up tasks without having to go via the usual tendering process, which would otherwise allow an issue that is identified today to be considered only in a proposal for next year's tendering budget, so there would be quite a delay.
(I don't know whether that's possible, but maybe, some longer-running contract to be able to hand out additional smaller work items flexibly as needed might be a solution, once the initial work has been finished.)

Best regards,
Michael

Completely agree with what you said.

Hi Kendy,

Michael, please - would you be willing to further your (and Sophie's)
idea in form of a document that can be discussed as a whole,
particularly how the details together fit the TDF mission?

I think Michael provided very relevant feedback in many areas (thank you!) but it would be unfair to impose on him to also start writing documents which should be prepared with the help of our team.

As I started the proposal I'm very happy to work with Sophie and Hossein to complement the proposal with the useful feedback we received in this thread.

Ciao

Paolo

Hi Italo,

Italo Vignoli píše v Čt 10. 02. 2022 v 18:28 +0100:

I would have applauded a reaction to the message that has opened
this
thread which was integrating the proposal with some additional
thoughts
and suggestions, to specify which could be the areas where a
developer
hired by TDF could work for the common benefit of the project.

I see, thank you for the explanation!

I have expressed elsewhere in this thread that I am a proponent of
hiring more development mentors rather than generic developers; so it
is hard for me to get excited about this proposal.

Also I forgot to answer Heiko elsewhere that his idea of graphics
designer / website developer in one person sounds reasonably positive
to me.

Having said that, maybe we can get a bit more constructive even in this
  discussion about hypothetical possibility of hiring generic
developers; so what about this:

Michael, please - would you be willing to further your (and Sophie's)
idea in form of a document that can be discussed as a whole,
particularly how the details together fit the TDF mission?

I myself would be interested in the following questions; do you think
you can cover them some way, please?

I'm not Michael, but thanks for the helpful points.

* How to frame the hiring process - where developers should have a say
   in it, without being accused of CoI?

I would frame the role description to begin with as focusing on underloved areas and thus ecosystem company reps would be very welcome to participate in the interviews etc. As long as they refrain from poaching in the middle of the process :wink:

* How to make it quick, so that the potential hires are still available
   once TDF decides for this or that candidate?

Maybe time the interviews for a season of the year that we know is not rush hour for all of us.

* How to get the developers up-to-speed or mentor them once they are
   hired?

I suppose if the current mentoring capability is not sufficient for specific core hacking deep dives, contracting mentoring from domain experts in the commercial ecosystem would be an option.

* Also how to task them, how to day-to-day manage them, and how to make
   sure they are progressing at a reasonable pace?

I will go into the content of the imagined tasks at the end. Regarding smooth progress, one of my self-assumed responsibilities is to protect experts from noise and more trivial or repetitive things, so I think fostering this sort of a supportive environment would help.

* What to do if they get stuck, and there is nobody in the community
   who can help them?

Park the stuck task and work on something else.

* How to detect they are not performing, and just consume the donors'
   money?

The current way the directors monitor staff seems enough for this role as well.

* How to make sure they don't compete with other open source projects,
   or the ecosystem companies?

Trust the more experienced staff members to know this distinction when it comes to areas of focus.

* How to make sure they are not misused by (any, not only ecosystem)
   companies to fix bugs for them or for their customers? [Particularly
   companies disguised by @gmail or so addresses in bugzilla.]
> * On the other hand - how to make it possible to cherry-pick fixes or
   features into the release branches of ecosystem companies without
   the risk of being accused of misusing the previous point?

This kind of activity seems detectable by staff, but the previous answer also applies. If some traditionally underloved area would suddenly get regular bug reports, it would in itself draw a lot of attention. Yet, instead of defining some sanctions, I think it would be best to not stress about edge cases no one can fully control, if the end result is shipping good stuff to everyone anyway.

* Should there be a mechanism for the ecosystem companies to flag a bug
   "this is what I'm working on for a customer - please don't touch"?

I'm not sure if it's needed, but this mechanism could be a string placed in the Whiteboard field of a report.

* With my pet idea of development mentors rather than generic
   developers in mind - should they be mentoring too, and if yes, how
   to prioritize vs. the actual development?

Yes, they should be. The prioritisation arises organically:
1. there is the huge mass of people I mentor
2. not all of the people from point 1 even reach the level where Hossein becomes their primary mentor
3. for the core hacking level, the hypothetical staff devs could share the mentoring responsibility, optimally on the areas they themselves are working on

* How to avoid growing a group-think in the internal developers
   group that there is no need for the ecosystem companies, or even
   for the community as a whole? [As explained elsewhere; as much as
   it sounds strange - TDF is a subset of the community, not the other
   way around.]

By regular brainwashing sessions conducted by me (I am well-known for my free advertising of the ecosystem companies before and after my hiring at TDF).

* How to avoid TDF internal developers to feel (or worse, to be)
   "more equal" than the rest of the community - particularly when
   there is no 1/3 rule for them, direct access to release engineering
   and admins (their colleagues), etc.?

A possible answer to this is the content of the tasks.

What came to my mind about possible tasks when I thought of this in-house dev role are things like

- drafting and reviewing tenders (faster and improved experience for ecosystem companies)
- code reviews (both to support ecosystem companies and to decrease the workload of their employees on reviewing random patches - sometimes this is done on their free time after all)
- GSoC mentoring (less pressure for ecosystem companies as this can get tedious)
- "orphaned regressions", from committers who left the project or ecosystem devs who won't get paid for fixing an ancient mistake (this would be a big stress relief for devs in the ecosystem companies who have a heightened sense of responsibility to fix stuff on their free time)
- any underloved thing!
- fixing build breakages
- keeping the toolchain well-oiled
- improving developer experience in myriad ways, including making existing code easier to reason about

All in all, I just see this as a no-brainer and a huge boon for the ecosystem companies. It would remove a lot of distraction from the workdays of company employees and give the sense that they are not the only Ghostbusters in town that get called to solve the newest crazy phenomenon.

Regarding the topic of volunteers vs. paid devs, for sure the directing of volunteers has become easier with the new structured approach to mentoring, but we have to consider the aspect of velocity. It is awkward, if some parts of our ambitious application suite are dragged along in a sort of half-dead state, while others flourish. If not much core hacking is going on somewhere, it becomes much more difficult to direct volunteers to it. A hired dev can reinvigorate an area of the suite and create new easy hacks for it.

The web dev idea is off-topic in this thread, but such a person should definitely get hired for many reasons. It is true that a web dev would also improve the core developer experience by enhancing our tooling.

Ilmari

1 Like

Hi Ilmari,

thanks a lot for your contributions.

In the next few days I'll prepare a document with Sophie and Hossein combining also your comments so that we can start moving forward with a concrete plan and a job description.

I see that you are joining Heiko in proposing to employ a web developer.

I suppose that your proposal isn't seen by anyone as being problematic so if the team with the ED create a job description we could get also that approved fairly quickly.

Ciao

Paolo

Hi Paolo,

Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100:

As I started the proposal I'm very happy to work with Sophie and
Hossein
to complement the proposal with the useful feedback we received in
this
thread.

Perfect, I am looking forward to an ODT that we can then collectively
redline as the Board, to form a proposal based on consensus!

As to working with Sophie & Hossein - are you about to politely ask
them to work on that as volunteers (as I've asked Michael W. - Michael,
once again thank you for your input & answers!), or are you about to
ask your fellow Board members & Florian to dedicate some of their work
time (ie. donation money) to work on the proposal?

Thank you!

All the best,
Kendy

Hi Kendy,

I'm not Paolo,

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

Regards,
Andreas

Hi Ilmari,

Thank you for your answers, lots of great stuff! Just two notes:

Ilmari Lauhakangas píše v So 12. 02. 2022 v 23:30 +0200:

> * How to make sure they don't compete with other open source
> projects,
> or the ecosystem companies?

Trust the more experienced staff members to know this distinction
when
it comes to areas of focus.

I fear it shouldn't be about trust only :slight_smile: - so I'm looking forward to
the Paolo's promised document, I hope it will cover it some way too.

> * How to avoid growing a group-think in the internal developers
> group that there is no need for the ecosystem companies, or even
> for the community as a whole? [As explained elsewhere; as much
> as
> it sounds strange - TDF is a subset of the community, not the
> other
> way around.]

By regular brainwashing sessions conducted by me (I am well-known for
my
free advertising of the ecosystem companies before and after my
hiring
at TDF).

Love this one! :smiley: - thank you!

All the best,
Kendy

Hi Andreas,

Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100:

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

I've told it in the public part of the Board meeting on Friday, and
will repeat it again: I am very sad that this whole discussion started
framed as (let me paraphrase) "TDF will hire 2 developers, it is all
done deal, there are no problems" [in concrete words "Funds are
available for at least 2 developers allowing us to start employing them
straight away; Next steps: create and publish the job offers for
developers and on-board them ASAP"].

This is extremely unhelpful, as it totally dismisses views of others.
There was no full agreement of this in the Board, no plan, no
prioritization against other budget items and no consideration if this
is the best way how to improve the situation - so please don't be
surprised it lead to a challenging discussion.

I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and
others (I'm sure I forgot some, sorry about that) for their patience &
helpful input, and I do hope we will move to a more constructive,
concrete debate.

In my world [regardless of the hat], a constructive debate is much
easier over a document collecting:

* the problem statement & the need
* the pros & cons of various solutions
* the proposal & conclusion

That with change tracking (redlining) turned on & possibility to
comment - so that it is possible to finalize it to a form that is
acceptable for all involved: in other words, to form a consensus.

So - I am really looking forward to such a document! Actually I'd be
happy to start it myself, if that helped the situation; and would ask
people to volunteer to work with me on that - but not sure it is a good
idea just now.

All the best,
Kendy

Hi Kendy, all,

Hi Andreas,

Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100:

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

I've told it in the public part of the Board meeting on Friday, and
will repeat it again: I am very sad that this whole discussion started
framed as (let me paraphrase) "TDF will hire 2 developers, it is all
done deal, there are no problems" [in concrete words "Funds are
available for at least 2 developers allowing us to start employing them
straight away; Next steps: create and publish the job offers for
developers and on-board them ASAP"].

but that gave TDF the option to work on tasks which are important for
the LibO user and for the market strength of the LibreOffice community
edition.

This is extremely unhelpful, as it totally dismisses views of others.
There was no full agreement of this in the Board, no plan, no
prioritization against other budget items and no consideration if this
is the best way how to improve the situation - so please don't be
surprised it lead to a challenging discussion.

I'm sorry but it seemed the challenging discussion is done only by one
person.

And don't be surprised that there is not always full consensus in a
decision process. At some point you have to decide with the majority of
votes to avoid endless discussions.

I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and
others (I'm sure I forgot some, sorry about that) for their patience &
helpful input, and I do hope we will move to a more constructive,
concrete debate.

Maybe you made excessive demands on their patience and self-perception.

In my world [regardless of the hat], a constructive debate is much
easier over a document collecting:

I think it is (nearly?) impossible to take part in a debate, if you have
a CoI (because you sit on two sites of a table).

Regards,
Andreas

Hi Kendy,

Hi Paolo,

Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100:

As I started the proposal I'm very happy to work with Sophie and
Hossein
to complement the proposal with the useful feedback we received in
this
thread.

Perfect, I am looking forward to an ODT that we can then collectively
redline as the Board, to form a proposal based on consensus!

Thanks, I'm looking forward to having the board agreeing that it's the best strategic move for TDF to start employing internal developers.

I'm sure that if all board members think about the best for TDF we will reach an unanimous consensus on it very quickly.

As to working with Sophie & Hossein - are you about to politely ask
them to work on that as volunteers (as I've asked Michael W. - Michael,
once again thank you for your input & answers!),

As to working with Sophie and Hossein I have publicly asked members of TDF's team to work together on an opportunity that affects them, as we are talking about new colleagues, and on which they can share their thoughts and experience as they are working in many areas and are able to identify the best ways to get the new developers to be most effective within the team and for the good of our wider community.

True that I could have added the word "please", I was probably too excited to start working with members of the team and totally forgot, but I'm sure both Sophie and Hossein didn't get offended by it.

  or are you about to
ask your fellow Board members & Florian to dedicate some of their work
time (ie. donation money) to work on the proposal?

Our team must invest its time for the best of TDF, LibreOffice and the wider community and that's what our donors want.

Keep also in mind most volunteers are also donors as time for most of us has a value.

I'm generally selling my time at X amount per hour/day so I'm donating that value to TDF with the only scope of doing my best for TDF, LibreOffice and the community as I passionately believe on the project and the good that it's doing all over the world without expecting any economical return. Naturally there is a limit on the amount of time I can donate as while it makes me happy to be doing my best for TDF and the community, like anyone else, I have to dedicate my time also in doing things that pay the bills.

Others may be able to invest as much time as it is necessary as anyway some outcomes may be also quite beneficial for their own companies, that may create a bit of an imbalance in the decision making process.

Thank you!

Thank you for understanding how much many are donating in time and money to TDF and that we need to move forward to show them their donations really matter to us.

All the best,
Kendy

Ciao

Paolo

Hi Kendy,

On 14/02/2022 16:42, Jan Holesovsky wrote:

Hi Andreas,

Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100:

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

I've told it in the public part of the Board meeting on Friday, and
will repeat it again: I am very sad that this whole discussion started
framed as (let me paraphrase) "TDF will hire 2 developers, it is all
done deal, there are no problems" [in concrete words "Funds are
available for at least 2 developers allowing us to start employing them
straight away; Next steps: create and publish the job offers for
developers and on-board them ASAP"].

The proposal is a proposal not a contract.

This is extremely unhelpful, as it totally dismisses views of others. 
There was no full agreement of this in the Board, no plan, no
prioritization against other budget items and no consideration if this
is the best way how to improve the situation - so please don't be
surprised it lead to a challenging discussion.

I do understand your point of view as I found it “very regrettable” that my views and proposals that were clearly stated in my candidacy statement got dismissed by others.

I did have a conversation with the board trying to explain that this is a strategic decision that shouldn’t be seen as a ranked project but my point of view was totally ignored by those that didn’t care much about respecting others’ views.

Then others tried to dismiss my proposal trying to frame it as us vs others political battle:

’ + very regrettable (Simon)

  • to frame this as partisan - one side vs. another
  • particularly when one side is “the industry”’

That last line is also very regrettable as “the industry” (2 suppliers very well represented in the board) seem to be more equal than others and if we don’t listen to “the industry” very bad things will happen.

I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and
others (I'm sure I forgot some, sorry about that) for their patience &
helpful input, and I do hope we will move to a more constructive,
concrete debate.

It has been a very constructive debate which seems to show that most have understood that my proposal has many ramifications that will help TDF in moving forward in a positive way.

The good thing is that even the members of the ecosystem seem to have seen the proposal as beneficial for all the parties involved.

We should have more of these debates in public so that the team and the community can tell us if we are going in the right direction.

In my world [regardless of the hat], a constructive debate is much
easier over a document collecting:

* the problem statement & the need
* the pros & cons of various solutions
* the proposal & conclusion

Something like this?:

  • As shown by Italo’s slides at FOSDEM again and by others, TDF is not contributing as much as it could
  • Up to now no strategic decisions have been taken to make TDF a more regular and active code contributor
  • Members of the ecosystem and others also suggested that we should spend more money in development
  • Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem
  • We need to build up internal skills and development capabilities to speed up innovation
  • Lack of suppliers diversification, mostly 2 at present, is a suboptimal situation for TDF, LibreOffice and its community
  • Internal developers can grow to cover areas like mentoring and QA while also helping with new contributors support
  • TDF needs to expand its internal capacity to deal with publishing in app stores directly and manage variable levels of complexity due to ever changing rules
  • Some proposed projects could be developed internally instead of outsourcing them, which helps to grow in-house skills and capacity to address our donors needs
  • Potential App Stores revenues may allow for more developers and to invest in developing other projects
  • Our development mentor together with the team should propose to the BoD projects for internal development
  • While internal projects may cover different areas tenders and ESC proposals will be also evaluated to avoid effort duplication
  • This is not “just” a new project, it’s an essential and strategical move for TDF to grow further in its second decade which widens the horizon for new visions and opportunities to do more and even better things for LibreOffice and our community
  • Funds are available for at least 2 developers allowing us to start employing them straight away
  • Next steps: create and publish the job offers for developers and on-board them ASAP

This has allowed to get a feel for the proposal, which seems very positive, and now we’ll be working on the details but at least it showed that the community thinks we are moving in the right direction.

Then should the new developers invest 30% of their time in QA, 50% in bug fixing and 20% in reviewing tenders and deliverables?
That’s something we should see with the team as they have a very good feel of what is going on.

That with change tracking (redlining) turned on & possibility to
comment - so that it is possible to finalize it to a form that is
acceptable for all involved: in other words, to form a consensus.

We’ve done that or better tried to do that. When the initial direction is not yet set it has shown to be a total waste of time.

A good example was that third party company, we wasted months as some wanted to justify it at all cost while others where asking to look at the evidence showing that it was not a good idea at all. Lots of red lining and “vandalised documents” as some comments were pointing out what was actually seriously wrong.
Same thing happened for many other discussions.

Let’s do things in the open, let’s get the community to comment on the proposal and then we can work together to go in the right direction.

So - I am really looking forward to such a document!  Actually I'd be
happy to start it myself, if that helped the situation; and would ask
people to volunteer to work with me on that - but not sure it is a good
idea just now.

Be patient.

As a volunteer not earning any money with LibreOffice development or support I need a bit more time than others to liaise with the team members and start writing documents.

All the best,
Kendy

Ciao

Paolo

I think at least some of the push back is less against the concept that
TDF should hire developers and more that it's a clearer path to start
with some specific problems and then what options could solve them and
hiring can be an option on that decision tree. It's a rare dev that has
skills in multiple appstores, mentoring, qa, a11y, CTL, CJK and
bugfixing in the various quite diverse components.

Hi Caolán,

thanks for your feedback.

I think at least some of the push back is less against the concept that
TDF should hire developers and more that it's a clearer path to start
with some specific problems and then what options could solve them and
hiring can be an option on that decision tree. It's a rare dev that has
skills in multiple appstores, mentoring, qa, a11y, CTL, CJK and
bugfixing in the various quite diverse components.

Keep in mind that the point of the proposal was to get feedback from the community and the team which seems to confirm that it is desirable to have in-house developers to take care of certain areas.

Now that we know we want in-house developers, the team and the interviews will help in determining which areas we can start covering.

We have already identified that we have the in-house skills to manage the app stores but internal developers, together with external expertise if necessary, can help in adapting LibreOffice packages to deal with the eventual changes and issues that may arise when app store rules change.

If interviews show that there are interested parties that are also specialised, or have a good grasp, of a11y, RTL and CJK then that will help in determine what they will cover otherwise we will need to see if they can and are interested in growing their skills in those areas.

Developers could also dedicate part of their time in QA and mentoring while helping in validating tenders and their deliverables so I'm sure that nobody will get bored and everyone over time will have the opportunity to show in which areas they perform best.

At this stage there are many areas that need to be covered and everyone in the team has demonstrated to be capable in adapting and perform many different tasks. The same adaptability will be, at least at the beginning, appreciated from the new members of the team.

Over time funds coming from app stores and donations will allow us to further grow our team and will allow members of the team to focus more in specific areas if they wish.

I'm fully aware that this is not the way established development/consulting companies work but TDF isn't one and it needs to build up its internal skills organically for the reasons explained in this thread.

Ciao

Paolo

It is recognized that in-house developers (...) may be a (partial) solution some of the issues we face.
So I really look forward to the proposal you are working on that will address all the ideas and questions we saw in the discussion so far.

Cheers,
Cor

Hi *,

Cor Nouws wrote:

> Now that we know we want in-house developers, the team and the ...

It is recognized that in-house developers (...) may be a (partial) solution
some of the issues we face.

Yeah it is a bit annoying, having to repeatedly state this is an
ongoing process.

From the board call minutes just posted:

    + Proposal: discuss more, decide with strategy workshop? (Lothar)
      + could be interesting (Paolo)
      + a consensus from one side brilliant idea to have it
      + other side seems like its a better idea for the ecosystem to
        do that

A "consensus from one side" is not a consensus, and not a decision.

Currently, both the old and the new board are ranking all budget
proposals. We will see what comes out top, if there's budget for it,
and how the board & TDF can then execute on those items we want to do.

And to conclude: the easiest way to convince me (and likely others) on
the board that a proposal is a good idea - is to make your case
properly with a well-researched writeup. Repeatedly claiming that all
is clear, and why haven't we hired yet - is not convincing, to say the
least.

Cheers,

-- Thorsten

Hi all,

Hi *,

Cor Nouws wrote:

Now that we know we want in-house developers, the team and the ...

It is recognized that in-house developers (...) may be a (partial) solution
some of the issues we face.

Yeah it is a bit annoying, having to repeatedly state this is an
ongoing process.

I feel it's a bit like saying we need a marketing plan and somebody complaining that that's not good as it maybe only a partial solution of the issues we face.
Well, now you have a marketing plan and some of the issues are being sorted.

We face many more issues and a couple of developers will start easing some of them but once again it's a good step in the right direction.

Then we'll deal also with the rest.

From the board call minutes just posted:

     + Proposal: discuss more, decide with strategy workshop? (Lothar)
       + could be interesting (Paolo)
       + a consensus from one side brilliant idea to have it
       + other side seems like its a better idea for the ecosystem to
         do that

A "consensus from one side" is not a consensus, and not a decision.

The wider community and our own team seems to indicate that employing developers is actually a good idea.

Even within the budget another member of the board proposed a new employee dedicated to QA so it seems like the need is there and I'm sure that 2 developers dedicating some of their time helping in QA and agreeing with the team which bugs should be fixed would help in speeding up things for both tasks.

Currently, both the old and the new board are ranking all budget
proposals. We will see what comes out top, if there's budget for it,
and how the board & TDF can then execute on those items we want to do.

So it seems like you are totally ignoring the feedback from the team and the community as you keep want to rank a strategic decision like any tender.

We know that the budget is there and that we can move forward.

The fact that you want to put them in a ranking sheet seems to show that you haven't yet understood the proposal from a strategic point of view.

And to conclude: the easiest way to convince me (and likely others) on
the board that a proposal is a good idea - is to make your case
properly with a well-researched writeup.

Could you please forward to me the well researched write-up used to employ the new mentor so that I can use that as a template?

Repeatedly claiming that all
is clear, and why haven't we hired yet - is not convincing, to say the
least.

It is clear that we should employ developers but the details as explained in a few emails well be worked out with the team.

Cheers,

-- Thorsten

Ciao

Paolo

It does still feel somewhat cart before horse in the sense that it
starts with a premise that hiring developers is the best solution and
then backfills it with the problems to solve. And I can understand
reluctance to go straight to that conclusion without stepping through
it starting from some specific priority problem areas to make sure
funds are distributed as wisely as possible to get the most tangible
reward.

Hi Paolo,

Paolo Vecchi píše v Út 15. 02. 2022 v 17:09 +0100:

> And to conclude: the easiest way to convince me (and likely others)
> on
> the board that a proposal is a good idea - is to make your case
> properly with a well-researched writeup.

Could you please forward to me the well researched write-up used to
employ the new mentor so that I can use that as a template?

The difference is that we already have a mentor (actually several
mentors in several areas), while you suggest a strategic decision -
which in my view deserves research, consideration from multiple views,
listening to others & consensus.

All the best,
Kendy

Hi Kendy,

Hi Paolo,

Paolo Vecchi píše v Út 15. 02. 2022 v 17:09 +0100:

And to conclude: the easiest way to convince me (and likely others)
on
the board that a proposal is a good idea - is to make your case
properly with a well-researched writeup.

Could you please forward to me the well researched write-up used to
employ the new mentor so that I can use that as a template?

The difference is that we already have a mentor (actually several
mentors in several areas), while you suggest a strategic decision -

We recently employed only 1 mentor.
No one else has been employed in that specific role.

Are you able to forward to me the document where the case has been presented "with a well-researched writeup"?

which in my view deserves research, consideration from multiple views,
listening to others & consensus.

We did the research in public, we had mostly 2 views, some have been listening to others and it would be great to recognise that there is a consensus that in-house developers are a desirable outcome which brings benefits to all.

It is sometimes not clear to me if the undefined objections to enabling TDF to be a more active contributors in areas not well covered by others are coming from members of TDF's board of directors or representatives of "the industry" which sells LibreOffice development services.

It would be great if members of the board of directors, with their TDF hat on, would explain clearly why they seem to be opposed to employing in-house developers.

All the best,
Kendy

Ciao

Paolo