Op 28-10-2020 om 08:29 schreef Quentin Christensen:
Thanks Florian,
Given the increasing use of open source software such as Libre Office in
government and corporate use, it is disappointing it isn't more of a
priority. Not being accessible does explicitly exclude LIbre Office from
most government use for instance.
Yes
I understand the difficulties with not
having any paid developers you can direct to do particular work, but it
does make the product specifically impossible to use for large segments of
potential users.
There are multiple factors at work I assume
- They group of users of accessibility (no-offense) is relatively small.
With less of incentives (getting different at the point being a
pre-requirement for governments/NGO)
- Most/All Developers themselves don't use accessibility (I speculate)
- There are not many people at QA/UX who have knowledge about (or use)
accessibility tools structurally (I assume)
And if they do they might have the actual handicap (so paying less
attention to the stuff being a problem)
- There or not many reports of accessibility bugs (I think)
- LibreOffice being in principle being developed by Selling Developer
Time (instead of final 'product' with certain functionality)
And there is no centralized organization paying. So this tends to put on
hold.
I'm personally and advocate for more bug fixing (or in general quality
control). Nobody is inclined to pay for solving bugs.
Everybody expects someone else will do. Or work around it. Hurting the
general user experience.
In my vision there needs to be an upfront investment (financed by
eco-partners) with a (substantial) higher product price,
to make returns on investment. This would also make it possible to embed
some kind of solidarity. The revenue - payed by all users - can be used to
serve a niche (accessibility). Instead of a niche having to pay to full
price; which doesn't make sense for the broad audience.
Same hold true for bug fixing. About bug XYZ a user ABC might not care
but D does. So not likely to get solved.
Or D has to pay. However, nobody actually knows if there is only 'D' or
a bug is simply under reported. People try LibreOffice,
notice it fails on their needs, and move on.
However they approach is for developers more easy to manage. Investing
in advance has a risk of failure,
if you don't estimate the desires from users properly. So you make no
return at all.
And you gets of debates/arguments about priority's. What should we do
next.. And everybody will come up with something.
Having different accents/visions. Say there is a budget for fixing 100
paper cut bugs and lets say we have 3000 of those.
File Export has multiple flaws. A single paper cut bug fix, still leaves
a broken feature. So pretty pointless. To make worth the effort 5 needs
to fixed.
But who uses File Export. Why File Export and not 5 accessibility bugs.
But there 100 accessibility bugs; which should have priority
I wonder how other FLOSS projects handle this?
Me too. It sounds like it's functioning there? Any examples?
Kind regards
Quentin.
On Wed, Oct 28, 2020 at 5:59 PM Florian Effenberger <
flo...@documentfoundation.org> wrote:
Hi Quentin,
Quentin Christensen wrote:
Was there any discussion about accessibility and if so, did anything
come out of it?
there was no separate discussion about accessibility. It is one of the
topics the board has in their ranking, to determine the
importance/priority of the topic - but we didn't discuss it in detail.
Florian
Regards,
Telesto
--
To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy
