Hi Paolo,
thanks a lot.
I haven't added an extensive list of bugs or improvements in the main
document as I think we should, with your feedback and with TDF's team,
create a set of addendum for each area.
Regardless of the progress of this proposal I will ask the board to
involve TDF's team to formalise a selection of issues/bugs that need
attention in the listed areas so that, depending on the level of
readiness of the developers, they can straight away start working on
them. I naturally ask all of you to help the team by sharing your point
of view in this thread.
By "formalise a selection of issues/bugs", do you mean to to create a
list of specific tickets that should be worked on in the mentioned
areas? If so, I'm wondering whether that's already needed at this point
of the process of trying to find a consensus on the general direction.
I'd expect that creating a proper, ranked list of issues would be a
large task by itself, and with the "TDF developer should be(come) the
topic expert" approach, I'm wondering whether it wouldn't be enough to
identify potential areas to be worked on for now.
For the areas mentioned in your proposal, existing meta bugs/Bugzilla
keywords might be a good starting point:
* RTL/CTL: meta bug tdf#43808 [1]
* CJK: meta bug tdf#83066 [2]
* a11y: meta bug tdf#101912 [3], and "accessibility" keyword [4]
* MSO interop: meta bug tdf#107585 [5]
* regressions: "regression" keyword [6]
FWIW, for a11y, a blind user with whom I got into contact via LO's a11y
mailing list has also made a personal ranking of issues related to using
LO with the NVDA screen reader on Windows that he'll most probably be
happy to share with anybody who's interested.
Please do let me know what you think of the draft proposal and how it
could be improved.
I'm not familiar with what such kind of document for BoD
discussions/decisions should look like in general and I don't want to go
too much into detail about specific passages; just a few personal thoughts:
I think the proposal has many good points. I'm not sure whether it
already addresses all the concerns others have brought up earlier, but
others can certainly speak for themselves best. In any case, I think it
would be essential to continue discussing in a constructive way and try
to find a consensus together, and having having this document as a basis
for discussion now seems very helpful.
My own focus for having developers would be less to "compensate eventual
other drops in contributions" (p. 4), since I think the goal there
should rather be to ensure an environment where others, including
ecosystem companies, are happy to start/continue contributing (more) -
which is also explicitly listed as a goal.
Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate
that topic from the current discussion, which I think makes sense.
I think it would make sense to focus on identifying non-controversial
areas that should be worked on (e.g. what's listed as "Focus areas" from
page 6 on) and then see how internal developers could help there, but
also leave room to discuss potential alternative solutions.
Regarding interoperability with MSO (p. 6), I don't have the impression
that this is in general a neglected topic that would necessarily need
special attention from TDF side at this point (in addition to what's
already happening e.g. via tenders).
The "Knowledge Sharing" section (p. 5) has this:
The additional positive side of creating a team of in-house developers is that
TDF will be able to
accumulate and share knowledge and become the neutral forum where all
contributors can
exchange information and learn how to contribute better and more to LibreOffice.
It's not clear to me what exactly is meant by this. I don't see any
general need to find a different/additional "forum" to exchange
information in addition to what developers already have right now, at
least nothing that would directly be related to the question whether or
not TDF hires internal developers. (IMHO, TDF developers should in
general just participate by the same means that other developers do,
though of course they might have a stronger focus on supporting others
in learning how to contribute better.)
Best regards,
Michael
[1]
https://bugs.documentfoundation.org/showdependencytree.cgi?id=43808&hide_resolved=1
[2]
https://bugs.documentfoundation.org/showdependencytree.cgi?id=83066&hide_resolved=1
[3]
https://bugs.documentfoundation.org/showdependencytree.cgi?id=101912&hide_resolved=1
[4]
https://bugs.documentfoundation.org/buglist.cgi?f1=keywords&list_id=1423830&o1=substring&query_format=advanced&resolution=---&v1=accessibility
[5]
https://bugs.documentfoundation.org/showdependencytree.cgi?id=107585&hide_resolved=1
[6]
https://bugs.documentfoundation.org/buglist.cgi?f1=keywords&limit=0&list_id=1423829&o1=substring&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=---&v1=regression
--
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
