Hi Michael, all,
On 10/02/2022 17.53, Michael Meeks wrote:
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...
Best regards,
Michael
--
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
