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

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

Hi *,

looking at this thread, we start to run in circles.

My understanding was, that Paolo volunteered to write-up a more
detailed proposal, including goals (short-term and possibly
long-term).

I agree with several other directors (current and upcoming) that this
would be very useful to have, to base a decision on.

So lets wait for that document; in this sub-thread there was no new
arguments in a while. I suggest we retire it.

A few quick comments, no need to discuss further:

Paolo Vecchi wrote:

> 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.

TDF employed, and still employs, several mentors in various roles &
overlapping responsibilities (including development).

Those were, if my memory serves me well, unanimously wanted.

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.

The opposition seems to be about the process, and about putting the
means before the end. There was BTW a constructive side-thread with
some thoughts on how/where a salaried developer at TDF could be
beneficial, with contributions from all sides of the aisle.

Best,

-- Thorsten

Hi Paolo,

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

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.

I have never said I am opposed (and never said I'm supportive) to
employing in-house developers, because I don't have enough information
to make an informed decision yet.

I have said two things:

* I'd prefer hiring development mentors, rather than developers,
  because I am convinced that that is the best way how to scale as
  an organization responsible for the source code, and I see less
  potential problems with that

* I am unhappy how the proposal to hire developers was and is being
  pushed, with lots of wishful thinking, and on the other hand without
  outlining potential problems, without proper discussion of the
  pro's & con's of this or other solutions, and without outlining
  details of tasking and management of the developers.

In other words, my view is that the "let's first hire 2 developers, and
then see" approach is irresponsible, and we should have a plan first.

That is why I am so grateful to those who have constructively
contributed to the debate, and particularly to those who have added
their thoughts as answers or responses to my questions!

All the best,
Kendy

Hi Kendy,

In other words, my view is that the "let's first hire 2 developers, and
then see" approach is irresponsible, and we should have a plan first.

I would agree with you if that were the case.

The bullet points of the proposal already presented some reasons and started delineating a plan for it, many contributions to the conversation added to that plan more details.

Email threads show that concepts may be difficult to follow but if you read through the emails you would notice that I proposed that the team and the suitable developers will start shaping what we could be focus on from the beginning.

As already said, if we find an excellent a11y developer and one that has already got experience in fixing bugs in some unloved areas then the initial choices would be already made for us. If we only find "generic" C++ developers then naturally we'll have to train them in specific areas which the team will identify.

Naturally, as said in this thread, the developers need to be initially quite flexible and learn to cover different areas including QA and mentorship.

While the team adjust and we discover specific preferences for those developers then they could focus in an area more than others so that they can express their full potential.

Is the "plan" a bit clearer for you now?

I'll find the time to collate together the feedback received by many that help in completing the plan.
Just give me a bit of time this is an activity I do by donating my time to TDF without expecting an economical return so I have to tend to other things as well.

Ciao

Paolo

Hi Paolo,

Paolo Vecchi píše v St 16. 02. 2022 v 15:04 +0100:

Is the "plan" a bit clearer for you now?

Thank you, sounds much more positive this way.

I'd still call it more an "outline" than a "plan", but I can see
potential for the development mentoring in that too, so I can imagine
we can agree something great for TDF together as the Board.

I'll find the time to collate together the feedback received by many
that help in completing the plan.

The devil is always in the detail, but I'm all ears & patient too,
please do take your time - I'm really looking forward to the plan.

Again - thank you!

All the best,
Kendy