Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index


On 14/01/2022 20.24, Paolo Vecchi wrote:
Personally, I'm not interested in playing zero-sum games (taking
development away from the ecosystem, and re-patriating it into
TDF). Instead, we need to work much more on creating win-win setups,
and supplementing each other.
TDF must make its choices as corporate contributors have to make theirs.

Fortunately corporate contributors have business models that allows them to grow without counting on TDF tenders so, while tenders will be still made to deal with complex development that other contributors are unable to tackle, we need to become capable of managing some of the project so that we are not always dependent on third parties that may not find a specific project fun or commercially interesting.

That sounds like a good approach to me.

There's definitely things that TDF can do much better than any
ecosystem company. There's also definitely things that ecosystem
companies are likely better suited for, than TDF. The same is true for
our volunteer community
True and that's why there is room for all to have fun and participate to make LibreOffice and related project great.


One obvious area where there's very little commercial incentive to do
things is a11y. At the same time, that would be something very
charitable to fund & further! If there's budget for funding internal
development, a11y would be very high on my list of topics to focus on.
That's something that has been on the list to do for a long time.
I haven't noticed anything related to it in the ESC ranking or maybe it's simply not marked clearly enough.

If it isn't there then we should ask the ESC to propose fixes in that regards?

I think one point here is that doing a proper proposal for a tender requires having a rough understanding of the subject to be tendered, be able to define a reasonable scope and also give a rough estimation of how much work that will be. In other words, it either requires somebody who already has an overview and a good idea what to suggest, or somebody investing time to come up with something.

Regarding a11y, as somebody who started looking into that topic, but without a clear idea on anything more specific for tendering, I had created this suggestion for tendering some (still to be selected) bugs from the a11y meta bug in Bugzilla: [1]

I must admit that I wasn't too disappointed that the suggestion didn't make it into the top list in the ESC voting. Given that more time would have been required to further analyze bugs in question and select a reasonable subset for the tendering, I am not sure whether the overhead (on all involved sides) would much outweigh the effort, or whether it makes more sense for me to spend time in trying to improve a11y myself.

I think tendering works best for items where the scope is clear beforehand, while here it would be much easier to say: "Here is a ranked list of a11y issues, spend X days on fixing as many as you can.", which to my knowledge doesn't really fit the tender model particularly well.

Maybe others have better ideas on potential a11y topics to tender or there are better ways to handle this, that's just the story behind the above-mentioned proposal... (which is the one clearly related to a11y in the list of proposals that ESC was voting on, [2]).

Best regards,


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.