Hi Michael, all,
There is a huge amount of need around LibreOffice development. It is easy to find a hundred different "top priority" issues each dear to the heart of a user, each user convinced that if only we had eg. 'Reveal Codes' in writer everyone would use LibreOffice.
True, and I think there is consensus that not everybody's personal "top priority" issue can be handled, no matter what steps are taken in the end.
As for no-one listening to users - I spend my life listening to customers & partners & users - and trying to do what they want. Anyone jealous of some big pool of unconstrained money / development power in corporate contributors is mistaken. Nevertheless I still get impassioned complaints of why Collabora did X and not Y from intelligent, articulate, engaged community members.
To mention it explicitly: Thanks for all that you and Collabora are doing for LibreOffice, that's much appreciated and I think nobody here is expecting Collabora to solve all problems by itself.
TDF in contrast while it has many constraints on what it can do - has few time constraints on its spending, which frees it to do more strategic long-term work. Thus it can invest more efficiently with some multiplying factor - via the educational / mentoring role into specific areas. I for one would support some targeted a11y / CTL mentoring - those seem like good areas that Sophie outlines - and ones where we can perhaps shine & grow the contributor community.
However - there is a cliff-face of need here. It seems totally sensible to suggest that hiring internal developers without any plan of working out what they should work on seems premature. Part of why mentors are attractive is that their agenda is partly lead by what volunteers want to do. That can be steered of course by creating new easy-hacks / tasks / projects in directions they want to go - and/or learning on the job themselves by hacking on things.
I completely agree that TDF has different constraints than other contributors and that could allow, among others, for doing more strategic work, rather than only focusing on single bugs that are important to specific users.
I'm not so sure, though, whether mentoring alone will be enough to ensure that otherwise neglected areas will sufficiently be taken care of.
For that to work, there at least need to be capable people willing to be mentored and to work on those topics, and having a certain amount of time to do so. I'm skeptical whether having more mentors alone will necessarily also provide for that.
I am wondering whether dropping a strict distinction between the two roles (developer, mentor) might help here. My expectation would be that a TDF developer currently "responsible" for a certain area would also be a great mentor in case people willing to work on that show up.
And once other contributors are willing to take care of specific areas, I believe it makes sense to allow them to work on that and have TDF staff focus on something else.
I think some flexibility depending on how things develop would nicely be able to deal with both scenarios: the one where other contributors interested in a specific topic show up, as well as the one where they don't.
For myself, I would want to see some sensible mechanism that includes the views of those who contribute via donations as to what is important. Then again if we dedicate donations solely in-line with what donors want - I suspect certain key functions: admin, marketing might not get the attention they deserve: so again, there is no obvious solution here beyond the board getting wide input and deciding (as they do now).
While I understand that details need to be sorted out on how to prioritize potential development topics to be worked on, I believe it should be doable to find a way.
But I don't see the issue, as ESC and BoD members could easily stop
any project before it starts, when there is a potential risk of conflict.
These days the we have created rules to exclude people from such decision making - which has the potential to significantly exacerbate conflict and division I feel.
But you're right, in theory the BoD is sovereign.
In my previous email, I wrote:
"Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all."
I admit that this will probably be very hard if members of the involved LibreOffice/TDF bodies don't find a way to work together constructively, but rather "fight against each other". But I think that's a problem on a completely different level, and I don't see how TDF can properly serve it's purpose then anyway, regardless of the specific question around TDF-internal developers being discussed here...