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

Hi all,

many of you voted for me as you wanted me to promote and achieve the goals set in my candidacy statement:

https://listarchives.documentfoundation.org/www/board-discuss/2021/msg00279.html

Point 1 is what leads me once again to share with the community my intention to push forward point 3 and 4 so that you can all provide your objective contributions to help me and the rest of the board in doing the right things for TDF and our community.

The following is a summary of the points that support the need and the feasibility of the proposal:

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

  • 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

The proposal will be publicly discussed this Friday 11 of February so I’m looking forward to your constructive feedback to make it a better proposal for all.

In the meantime I hope you appreciated my efforts in relation to point 6:

https://blog.documentfoundation.org/blog/2022/01/27/bug-bounties-finding-and-fixing-security-holes-with-european-commission-funds/

Ciao

Paolo

Hi all,

Paolo Vecchi píše v Po 07. 02. 2022 v 19:16 +0100:

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

My candidacy statement was much more focused on the community growth;
so I'd like to propose a different vision:

  TDF should be a pleasant place for contributors to feel welcome.
  TDF should focus on growing the community, mentoring, and welcoming
  newcomers.

I don't think that paying in-house developers is in line with this
vision; if we talk about TDF employees or contractors, we need more
mentors - because that is the only way how to scale:

  "Give a person a fish, and you feed them for a day. Teach a person
  to fish, and you feed them for a lifetime".

This is what TDF should be doing in my view - teaching how to fish, not
fishing itself.

All the best,
Kendy

Hi Paolo,

Hi all,

Thanks for discussing your proposal here. Just wanted to add a few words within your lines, so jumping here:

[...]

* 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

I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too.

That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use.
Cheers
Sophie

El 7/2/22 a las 15:16, Paolo Vecchi escribió:

Hi all,

many of you voted for me as you wanted me to promote and achieve the goals set in my candidacy statement:

https://listarchives.documentfoundation.org/www/board-discuss/2021/msg00279.html

Point 1 is what leads me once again to share with the community my intention to push forward point 3 and 4 so that you can all provide your objective contributions to help me and the rest of the board in doing the right things for TDF and our community.

The following is a summary of the points that support the need and the feasibility of the proposal:

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

  • 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

The proposal will be publicly discussed this Friday 11 of February so I’m looking forward to your constructive feedback to make it a better proposal for all.

In the meantime I hope you appreciated my efforts in relation to point 6:

https://blog.documentfoundation.org/blog/2022/01/27/bug-bounties-finding-and-fixing-security-holes-with-european-commission-funds/

Ciao

Paolo

I believe that the arguments in favor are way more than enough. TDF must set the course and have its own weight within ESC.
In addition, projects that are not attractive to the valuable members of the ecosystem could be divided into smaller parts and dealt with within the foundation itself.
We must avoid reaching an instance similar to LOOL, where one part simply closed the door. In that sense, influence and/or dependence on just two providers is not in the best interest of the foundation itself or the LibreOffice Community.

Hi Kendy,

thanks for participating to the discussion.

Hi all,

Paolo Vecchi píše v Po 07. 02. 2022 v 19:16 +0100:

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

My candidacy statement was much more focused on the community growth;
so I'd like to propose a different vision:

   TDF should be a pleasant place for contributors to feel welcome.
   TDF should focus on growing the community, mentoring, and welcoming
   newcomers.

I don't think that paying in-house developers is in line with this
vision;

I totally share your vision which is very much complementary to what I propose.

I've been a developer as well many years ago so I know how important is to have an open and relaxed environment where developers can exchange experiences and ideas.

Having in-house developers will make it easier to share the knowledge as developers can/should be also mentors enabling us to help more people.

  if we talk about TDF employees or contractors, we need more
mentors - because that is the only way how to scale:

   "Give a person a fish, and you feed them for a day. Teach a person
   to fish, and you feed them for a lifetime".

This is what TDF should be doing in my view - teaching how to fish, not
fishing itself.

The best person that can teach you how to fish is an experienced fisherman.

While we have an excellent Team that is doing its best, TDF needs to grow more in-house experienced fishermen that can help in making LibreOffice better while teaching others to do the same.

Even Mr Meeks confirmed today during the Team call that there is so much work that could be done to keep 100s of developers busy for a lifetime so it's likely we will have to employ more than 2 developers to do some actual development and also to enable new contributors to participate in the efforts of keeping LibreOffice as the best Open Source office suite available.

I believe TDF will be very well positioned to offer a neutral environment where everyone is welcome even in situation where contributors may be competitors outside this safe environment where we can provide experienced "fishermen" that will teach how to improve LibreOffice to all interested parties without distinction.

I'm sure we can work very well together in combining our complementary visions for TDF.

All the best,
Kendy

Ciao

Paolo

Thank you Sophie!

Having also feedback from the members of the Team is very important for me as you'll have to deal with your new colleagues as well :wink:

Please do reach out saying openly what you see right and/or wrong in this proposal so that you can help the board in making the right decision for TDF and our community.

Ciao

Paolo

Hi Paolo,

(...)

(..)

if we talk about TDF employees or contractors, we need more
mentors - because that is the only way how to scale:

"Give a person a fish, and you feed them for a day. Teach a person
   to fish, and you feed them for a lifetime".

This is what TDF should be doing in my view - teaching how to fish, not
fishing itself.

The best person that can teach you how to fish is an experienced
fisherman.

but it wouldn't improve the situation, if - like today - the experienced
fisherman / fishermen take every new talented fisher immediately from
the free software developer (volunteer) market.

Thus there is now chance for a divers market with a lot of small and
local businesses around the LibreOffice project. Thus the (business)
user of LibreOffice will not get the opportunity to choose between
different service provider.

If this situation will not change immediately the LibreOffice
certification program will not give a competitive edge.

Regards,
Andreas

Hi Andreas!

but it wouldn’t improve the situation, if - like today - the experienced
fisherman / fishermen take every new talented fisher immediately from
the free software developer (volunteer) market.

Thus there is now chance for a divers market with a lot of small and
local businesses around the LibreOffice project. Thus the (business)
user of LibreOffice will not get the opportunity to choose between
different service provider.

If this situation will not change immediately the LibreOffice
certification program will not give a competitive edge.

Do you believe TDF could spend donated funds on the salaries of developers who write LibreOffice, Andreas? As I recall when we were on the Board you asserted this would be an improper use of TDF’s funding under its bylaws?

For those unaware: TDF has previously extensively considered the proposal to employ LibreOffice developers, which is, as Daniel has commented, superficially very appealing. However, wanting something is not the same as it being possible to have something! The reasons we do not currently have internal developers include (among others):

  1. The question of whether TDF can spend money developing software. It has been asserted that it cannot.
  2. The question of who would decide what was written, and how, and how developers would be properly managed.
  3. Related to this, the moral imperative that TDF should not compete with its trustees.
    While I do not necessarily agree with the thinking behind these issues, any proposal before the Board would need a thoughtful and balanced proposal for resolving each of them. Perhaps one of the folk supporting the Board agenda item would like to write a paper that does that?

Cheers

Simon

Hi Simon,

Hi Andreas!

    but it wouldn't improve the situation, if - like today - the
    experienced
    fisherman / fishermen take every new talented fisher immediately from
    the free software developer (volunteer) market.

    Thus there is now chance for a divers market with a lot of small and

corrent sentence: 'Thus there is _no_ chance for a divers market with a
lot of small and'

    local businesses around the LibreOffice project. Thus the (business)
    user of LibreOffice will not get the opportunity to choose between
    different service provider.

    If this situation will not change immediately the LibreOffice
    certification program will not give a competitive edge.

Do you believe TDF could spend donated funds on the salaries of
developers who write LibreOffice, Andreas? As I recall when we were on
the Board you asserted this would be an improper use of TDF's funding
under its bylaws?

The only way to employ developers is for education and for science and
research (according to the statutes and the tax exemption). But the goal
has to be teaching others to work on the code and get some knowledge
(e.g. for the education part).

But if new volunteers get that knowledge, a certificate and were
talented developer they get very soon partner / staff of the biggest
market player. That would never lead to a divers service environment
around LibreOffice. Thus everybody who needs service around LibreOffice
will never get the opportunity (one strength of OSS) to choose between
service providers. There are other communities / OSS projects with
companies of different size and a divers project structure and no
company is dominating the project / community.

Regards,
Andreas

Hi Andras,

The best person that can teach you how to fish is an experienced
fisherman.

My example would be fruit grower and fruit picker (after all, the apple came before the fisherman :wink: ) but apart from that:

but it wouldn't improve the situation, if - like today - the experienced
fisherman / fishermen take every new talented fisher immediately from
the free software developer (volunteer) market.

Could be. After all it is one of the ideas behind for example GSoC.
On the other hand, in case it works out like that, it is good news on two fronts: apparently the commercial ecosystem party has enough income to hire someone extra; and also there still will be budget for us to hire mentors.
We also know that developers from commercial ecosystem parties are involved in getting mentors up to speed. So the whole picture does not have to look that bad, I think.

So spending that are intended to further grow the possibility of (relative new) developers to contribute (by mentoring, tooling, events), are a strong impulse to grow that side of the developer community and enabling more working people to help with code they think is useful.

Thus there is now chance for a divers market with a lot of small and
local businesses around the LibreOffice project. Thus the (business)

I remember we discussed possibilities in the past, that would enable relative independent new developers to get funded for work on LibreOffice. I think that is a good idea to grow the commercial ecosystem.

user of LibreOffice will not get the opportunity to choose between
different service provider.

Compared to various other open source projects, TDF/LibreOffice isn't doing that bad.
On the other hand, we can't blame projects for how they work as long as people are free to study, change, share, fork, ..

If this situation will not change immediately the LibreOffice
certification program will not give a competitive edge.

I love TDF for its work: being the place where all stakeholders meet and try to bring the best in the shared projects.
Then with my experience in a broad variety of commercial, volunteer and public entities, I'm far from convinced that it leads to anything good when a foundation tries to bend the forces that drive a commercial market.

Cheers,
Cor

Hi Simon,

Hi Andreas!

but it wouldn't improve the situation, if - like today - the
    experienced
    fisherman / fishermen take every new talented fisher immediately from
    the free software developer (volunteer) market.

Thus there is now chance for a divers market with a lot of small and

corrent sentence: 'Thus there is _no_ chance for a divers market with a
lot of small and'

And such chance exists right now?

local businesses around the LibreOffice project. Thus the (business)
    user of LibreOffice will not get the opportunity to choose between
    different service provider.

If this situation will not change immediately the LibreOffice
    certification program will not give a competitive edge.

Do you believe TDF could spend donated funds on the salaries of
developers who write LibreOffice, Andreas? As I recall when we were on
the Board you asserted this would be an improper use of TDF's funding
under its bylaws?

The only way to employ developers is for education and for science and
research (according to the statutes and the tax exemption). But the goal
has to be teaching others to work on the code and get some knowledge
(e.g. for the education part).

But if new volunteers get that knowledge, a certificate and were
talented developer they get very soon partner / staff of the biggest
market player. That would never lead to a divers service environment
around LibreOffice. Thus everybody who needs service around LibreOffice
will never get the opportunity (one strength of OSS) to choose between
service providers. There are other communities / OSS projects with
companies of different size and a divers project structure and no
company is dominating the project / community.

I think Andreas hits the nail on the head when he mentions that in other projects no company dominates the project or the community.

TDF has a development mentor, why shouldn't he be the one who decides what gets written, and how? I think it's not about competing with the valuable members of the ecosystem, it's about the foundation taking the reins of the project.

To give this discussion another spin: We pondered in the team about hiring a web developer. Someone between infra, code, mentoring and design. This person could also care about extension development (an area where users can participate in the development without knowing C++).

But in any case we are looking for a very special fisherwoman, and the experience from the past makes me think she's rather a mermaid than a real person.

Hi Daniel,

Daniel A. Rodriguez píše v Út 08. 02. 2022 v 19:31 -0300:

I think Andreas hits the nail on the head when he mentions that in
other
projects no company dominates the project or the community.

The contrary is true: Most of the successful open source projects have
a major, dominating company behind them - have a look at Nextcloud
(Nextcloud GmbH), ownCloud (ownCloud GmbH), MariaDB (MariaDB
Corporation Ag), ... and I can continue on and on.

In LibreOffice, there is no dominating company. Many like to paint
Collabora as one, but it is not the case due to how the founding
members (and I was one of them) have designed the TDF (with the 1/3
rule in the bodies and other means to protect from the project
domination) and due to how the German charity laws work.

Also, such thinking is very offensive to eg. Allotropia - who is doing
a great job undermining any kind of potential domination by excellent
engineering; have a look at their impressive WASM prototype.

But if you want to see an open source project with no company behind
them, have a look at Apache OpenOffice.

All the best,
Kendy

Hi Cor,

do you mind explaining to us what you mean with the sentence below?

I'm far from convinced that it leads to anything good when a foundation tries to bend the forces that drive a commercial market.

Cheers,
Cor

Ciao

Paolo

Hi Simon,

thank you for sharing your opinions with us.

On 08/02/2022 19:44, Simon Phipps wrote:

Hi Andreas!

On Tue, Feb 8, 2022 at 5:59 PM Andreas Mantke <maand@gmx.de> wrote:

but it wouldn’t improve the situation, if - like today - the experienced
fisherman / fishermen take every new talented fisher immediately from
the free software developer (volunteer) market.

Thus there is now chance for a divers market with a lot of small and
local businesses around the LibreOffice project. Thus the (business)
user of LibreOffice will not get the opportunity to choose between
different service provider.

If this situation will not change immediately the LibreOffice
certification program will not give a competitive edge.

I agree with Andreas that this is a great opportunity for TDF to extend its in-house skills which in turn could also provide more opportunities to enable new ecosystem contributors.

I’m sure there are many developers eager to join TDF to start working directly with the wider community with a great team that is with us not for the sake of having a job but because they passionately believe in what they are doing.

Do you believe TDF could spend donated funds on the salaries of developers who write LibreOffice, Andreas? As I recall when we were on the Board you asserted this would be an improper use of TDF’s funding under its bylaws?

It depends on the rationale.

If we perform specific tasks in-house, we create knowledge and skills within TDF that can be freely shared with the wider community. That’s a win-win for everyone. Accessibility is a field where we’re already active which requires further in-house investments but many other areas need further research and development to allow us to share documentation and knowledge which otherwise could be not made available by third parties.
There are many areas that are not economically relevant or interesting for volunteers and commercial contributors in which we must step in by investing in members of the team that will help in fulfilling our mission.

For those unaware: TDF has previously extensively considered the proposal to employ LibreOffice developers, which is, as Daniel has commented, superficially very appealing. However, wanting something is not the same as it being possible to have something!

For those unaware: some members of the current board had to fight hard since day one of their term to show others that a proposed project for a third party entity was suboptimal due to lack of proper analysis and investigation on what are the factors that could limit TDF.
The good thing that came out of that proposal is that finally we went through a proper legal analysis which has shown that some limitations that held back TDF were actually not there.

The reasons we do not currently have internal developers include (among others):

  • The question of whether TDF can spend money developing software. It has been asserted that it cannot.

It has been asserted through overdue legal consultations that we can invest money in many more ways that has been previously thought to fulfil our mission.

We now have a mentor that will train new developers, with varying degrees of experience, in how to develop for LibreOffice which will not only help in furthering the educational and research scope of LibreOffice with code but will also grow into mentors themselves allowing TDF to deliver more on its educational purpose and furthers its civic engagement which is another charitable purpose of TDF.

Not having had dedicated in-house developers did reduce our capability to fully deliver on our objectives, which are clearly stated in our statutes, so now that we have the necessary legal clarifications we should improve this situation immediately.

  • The question of who would decide what was written, and how, and how developers would be properly managed.

This is an organisational issue which will follow what is written in the proposal and I’m sure our ED, mentor and the rest of the Team will do a fabulous job in integrating the new developers.

In regards to what and how they will do it see my proposal. Depending on the skills that the developers already have they may initially focus on A11y or long standing bugs but then we will encourage them to grow in different areas so they can fully express the skills they are most comfortable with and that will benefit the community even more.

  • Related to this, the moral imperative that TDF should not compete with its trustees.

I see a few issues with this statement:

  1. How can we be in competition with trustees as they are individual members of our community who committed to help TDF and the rest of the community in many ways, not only code, to further our objectives?

  2. Even if you used the word trustees by mistake while you meant commercial contributors they surely read our statutes and our objectives so they positioned themselves to serve their own commercial clients without being concerned by TDF’s objectives.

  3. There is not only a moral but also regulatory and statutory imperative for TDF to pursue its objectives for the good of LibreOffice and its community so trustees and commercial contributors should actually be supportive and enable TDF in moving better and faster instead of trying to stop TDF in doing what it has been created to do.

While I do not necessarily agree with the thinking behind these issues, any proposal before the Board would need a thoughtful and balanced proposal for resolving each of them.

Now you should have a clearer view regarding the rationale behind the proposal and how the objections put forward are not valid any more.

All these issues could have been solved years ago but it seems we needed a suboptimal proposal presented at FOSDEM 2020 to start a process of verification and validation of what TDF can and can’t do.

TDF can and absolutely should invest in in-house developers to fulfil its objective for the benefit of the whole community while still complying with the parameters imposed by its charitable foundation status that have been purposefully chosen.

The community and our valuable members of the ecosystem have been asking us to invest more in development and now that we have finally gone through legal verifications we could start looking for new members of our team even today.

We can surely start within TDF and then evaluate over time if a fully owned and fully controlled subsidiary may allow us to deal with our growth in a more efficient way.

As it has been mentioned by a fellow director I looked at how the great people at Typo3 organised things. Typo3 is a non for profit that funds its fully owned company to deal with developers employment and commercial activities. It has been proposed to invite them to a board meeting to share their experience and we should actually do that so that we can evaluate a future option.

Perhaps one of the folk supporting the Board agenda item would like to write a paper that does that?

Putting the burden of writing papers on a member of the board is clearly not the most efficient way to deal with things and, as it happened already a few times, it gives the impression of being just a delay tactic for which I see no valid reasons.

I do appreciate that you learned from your past mistakes and that you now want to see more transparency and evidence that we actually did our research and analysis of the issues and the opportunities. There are documents available to the board which prove we did our job correctly but as they are part of interactions with legal experts the board will have to agree to make them public.

Cheers

Simon

Ciao

Paolo

Hi Paolo,

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

The community and our valuable members of the ecosystem have been
asking us to invest more in development

It is important to understand that "community" means "contributors"; as
opposed to "users". "Users" are not part of the "community", until
they start contributing; via code, QA, translations, marketing under
the TDF umbrella, etc.

With that in mind - can you please point us to those requests?

Thank you!

All the best,
Kendy

Hi Kendy,

Hi Paolo,

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

The community and our valuable members of the ecosystem have been
asking us to invest more in development

It is important to understand that "community" means "contributors"; as
opposed to "users". "Users" are not part of the "community", until
they start contributing; via code, QA, translations, marketing under
the TDF umbrella, etc.

With that in mind - can you please point us to those requests?

Sorry to be so insistent about RTL/CJK, but to illustrate what it means, see this bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=104597#c40
it is months on the ESC minutes and it's very impacting for Arabic versions. This is one on the top of my head, but there are more of them on fonts, etc.
If you look at the names commenting this issue, you'll see several contributors here.

Cheers
Sophie

Hi Sophi!

Hi Kendy,

Hi Paolo,

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

The community and our valuable members of the ecosystem have been
asking us to invest more in development

It is important to understand that “community” means “contributors”; as
opposed to “users”. “Users” are not part of the “community”, until
they start contributing; via code, QA, translations, marketing under
the TDF umbrella, etc.

With that in mind - can you please point us to those requests?

Sorry to be so insistent about RTL/CJK, but to illustrate what it means,
see this bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=104597#c40
it is months on the ESC minutes and it’s very impacting for Arabic
versions. This is one on the top of my head, but there are more of them
on fonts, etc.
If you look at the names commenting this issue, you’ll see several
contributors here.

Do you have any insight into why the community has not chosen to fix the issue please?

Thanks

Simon

Hi Simon,

Hi Sophi!

Hi Kendy,

Hi Paolo,

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

The community and our valuable members of the ecosystem have been
asking us to invest more in development

It is important to understand that "community" means "contributors"; as
opposed to "users". "Users" are not part of the "community", until
they start contributing; via code, QA, translations, marketing under
the TDF umbrella, etc.

With that in mind - can you please point us to those requests?

Sorry to be so insistent about RTL/CJK, but to illustrate what it means,
see this bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=104597#c40
it is months on the ESC minutes and it's very impacting for Arabic
versions. This is one on the top of my head, but there are more of them
on fonts, etc.
If you look at the names commenting this issue, you'll see several
contributors here.

Do you have any insight into why the community has not chosen to fix the
issue please?

Reading through the bug (which was only an example) and other contributions, I don't think we can say that the community has not chosen to fix their issues.

Cheers
Sophie

sophi wrote:

> Do you have any insight into why the community has not chosen to fix the
> issue please?

Reading through the bug (which was only an example) and other contributions,
I don't think we can say that the community has not chosen to fix their
issues.

Wasn't that meant to be tendered?

Cheers,

-- Thorsten