Hi Michael, thanks for the extensive contribution! :-)
On 24/02/2022 13:42, Michael Weghorn wrote:
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.
Yes the initial plan is to look at the general areas and then the team will work out with the developers which bugs they can start tackling on their own, with mentoring and/or with experts support.
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]
Thank you for the pointers, I've already added them to v1.5. Let's see how many other suggestions we'll receive and then I'll probably create dedicated addendum for each area.
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.
Are those issues that could be filed as bugs?The interest is surely there, let me check the best way to have it posted somewhere so that it will be evaluated for internal development and/or tendering.
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.
That is the whole point of the document ;-)At present it contains general guidelines and things we could/should do but with feedback like yours we can start adding more details that will help in guiding us.
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.
The focus is surely to increase the number of contributors and to help ecosystem companies in being successful with business models that bring benefits to them, TDF, LibreOffice and the wider community.
In the document you'll notice that I also wrote "clearly indicates that we need to work to foster new contributors with the help of new in-house developers and mentors."
The in-house developers are actually part of the strategy to help current and new contributors. Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked.
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.
The first part of the document presents the general strategy and the app stores are part of it. Surely we should start with creating an initial team that starts working on the "Focus Areas" but once they are settled and productive we should consider fulfilling our mission for users that are locked into app stores or just find it more convenient to used them instead of downloading LibreOffice Community from our site.
The topic isn't that controversial as it has been discussed at length in public and within the board. Even if my preference is to have TDF running the app stores, so that we can reinvest not only in development but also in other projects that help the wider community, there are still 2 proposals for business entities that would do just that and the members of the ecosystem are perfectly fine with it.
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 link that you provided for the metabug seems to show that there are a couple of bugs or three that need some attention.
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.)
Our goals include "Science and research, particularly in the field of computer science" so the creation of a dedicated development team will allow us to push deeper into areas of research and contribution to LibreOffice development and with those acquired skills we can extend further our other goal which is "Public and professional education".
Over time that could lead to the creation of new events and training material that can be shared to help further potential contributors.
Best regards, Michael
Ciao Paolo
[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
-- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint
OpenPGP_signature
Description: OpenPGP digital signature
