Hi Emiliano! Thanks for the feedback. I appreciate your thoughtfulness here, and I agree with you wholeheartedly.
On Thu, Feb 10, 2022 at 9:47 PM Emiliano Vavassori < [email protected]> wrote: > > I'd just question if a semi-finite number of tenders will solve forever > the specific needs of, just for the sake of the argument, a11y. What > decided that, for example, UX will have to be a recurring problem that > granted the direct employment of someone (thanks Heiko for your > efforts!) but a11y or RTL is not? > I agree it's non-obvious - but there was thinking behind it! For user experience, the expert (hi Heiko!) had to be an influencer and servant-leader rather than acting primarily as a developer as user experience design has a significant dimension of setting an overall direction and then persuading *all* the developers to follow it. In many ways this is more of a senior mentorship role, and the recipients of the guidance are not beginners but rather super-experienced developers who consent to being guided. The role is ideally met by having an expert on staff. (FYI I wrote about this <https://meshedinsights.com/2016/10/28/user-centric/> at the time) For accessibility, there are definitely elements that have a similar profile and a good argument could be made for having an accessibility architect on staff playing a similar role to Heiko in mentoring the "college of developers" to consider accessibility in their work. On the whole, the LibreOffice developer college is fairly tuned-in to accessibility though. 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. It's possible that RTL might surrender to the same approach, but that's not an area I have focussed on in my career so I'd want to hear from product managers who have dealt with it. I'd be open to whatever was the best solution. We need to discuss each of these topics on their own merits. > Honestly, I still feel there are parts of the project that would use > much more love and are definitely matter of inclusiveness, but for the > various reasons we already know very well and were even touched in the > discussion, are laying there suffering. > I definitely agree. I think it needs discussing and breaking down topic-by-topic though, as each area will have an optimal approach (and may have a different optimal approach once the backlog is dealt with). As in much of life, easy answers are unlikely to be correct answers! And yes, sure, employing internal developer is just one of the tools we > can deploy to assure a greater sustainability of the community and the > Foundation, and not the only one. > I'm also concerned by the "centralised service" challenges I mentioned in my earlier e-mail. I have thought about the subject a great deal, over several years, and I do think TDF could embark on a direction to serve the individual citizen in this area independently of the business solutions. But this is a topic where there are significant challenges from the vested interests of almost all the directors, so addressing it is going to be tough. I certainly don't want to "just hire a few people and see what happens" on this one! Cheers! Simon -- *Simon Phipps* *TDF Trustee*
