[board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Paolo, all, Paolo Vecchi wrote on 23/02/2022 17:01: ... You can find the draft which starts outlining various concepts and lists some of the issues we have to address here: https://nextcloud.documentfoundation.org/s/fM8pCesPnF2JjN4 Thanks for sharing that! From the various quotes/texts under ‘Rationale’, there are some that I consider real arguments to consider hiring developers and others expressing random support, but no arguments. To me, most pressing is improving the work in areas that are badly covered now, so bugs, accessibility issues and maybe some features. Another option, though it is to be seen of that can be realistically combined with the first, is areas like mentoring and new contributors support. Various things I read are a sort of: we need in house developers because we need them. It’s an argument too, but not the type I’m looking for. Then taking – as example – this one: “This drop in contributions, taking the Commercial group back to the 2018 levels, clearly indicates that we need to work to foster new contributors with the help of new in-house developers and mentors.” On what grounds is the statement that this ‘clearly indicates that..’ made? Of course, it could be a possible way to achieve that goal, yes, could be. A goal that “internal developers which will both increase the speed of development and will help with the on-boarding of new external commercial, corporate and volunteer contributors” also will come with some requirements and/or circumstances to make that work, I guess. And also that hiring by TDF is (likely to be) a very/the most effective way to achieve those. I struggle to understand “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.” I think this is not meant to say that the current LibreOffice development/team is not providing that? Among the various concerns that have been shared, and not only by commercial contributors.., for me the most problematic are having a good and realistic process to steer the work, and without possibly introducing in-house fighting left and right, as well as effectiveness of the spending, knowing the challenges for larger/complex code work. As expressed before, I’m willing to support a clearly defined trial since I consider that a good way to learn what is realistic and what is just wishful thinking. Cheers, Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- 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
[board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.02.22 15:43, Paolo Vecchi wrote: Hi Michael, thanks for your feedback. On 25/02/2022 10:22, Michael Meeks wrote: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? The macro categories can be easily worked out but here they are: Commercial contributors: * Collabora * CIB->Allotropia Corporate contributors: * RedHat last i worked there, LibreOffice was a fully supported part of Red Hat Enterprise Linux that customers could and did file enhancement requests for. * Assigned (a bit of a mix but volumes don't change much the result) err, no: these are people who are not contributing as part of their employment, although they *may* be paid Google Summer of Code interns. the way it works is that or people who contribute at different times with different employers, their contributions for their employer are counted for their employer, while their contributions with no employer are counted as "Assigned". * NISZ * SIL * Munich Volunteers: * Unknown (no official affiliation) and TDF own contributions. > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > development and will help with the on-boarding of new external > commercial, corporate and volunteer contributors. Why do you believe that in-house developers (vs. say mentors) will help with on-boarding new contributors if that is not their focus? My suspicion is that mentoring is hard and "doing it yourself" is superficially easy in the short term. As from previous answer: "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." i think what Michael meant is: how do you get an experienced developer to spend 3 hours discussing a problem with a newbie spread across a longer time period and giving them hints to fix it and review their work, instead of simply fixing it themselves in a single session in half the time, if their job title is "developer" and not "mentor". > and the quantity of bugs, features and updates that may require > tendering or paid for services by the commercial contributors is > still so vast that it will not affect noticeably their income While it is true that there may be an inexhaustible amount of work and TDF will never reduce that by doing some of it, I'm not sure that is really relevant. Tendering has been used by TDF to help stimulate, diversify and sustain the commercial ecosystem around LibreOffice since the beginning. TDF has a fairly fixed amount of cash - if there is less of that to spend, that will have a non-trivial impact. The methods tested up to now to stimulate and diversify the number of more commercial contributors haven't brought the desired result as it seems like mostly 2 companies bid for those tenders so we'll have to work harder on it. how do you expect to grow the number of companies who bid for tenders if there are not more tenders? N companies bidding for a tender means that N companies spend significant time doing estimations, but N-1 companies get 0 income for that effort. Worse than that though is the possible for TDF to significantly harm the market for bug-fixing far in excess of any work it can do - by creating the idea that there is a "free" way to have issues addressed through political machination at TDF. I'm concerned by your comment as you seem to put in doubt the neutrality and the dedication to the wider community of TDF's team. Reading it in another way someone may even think that "political machination" tried to stop TDF to fully express its potential for serving the wider community. Naturally not many people came up with those thoughts so I guess they really aren't an area of concern for most. i guess you aren't familiar with the history of this project, but this was very common in OpenOffice.org times: when a beta was released, suddenly a bunch of people came out of the woodwork to complain very loudly on public lists why bug X or bug Y had not been fixed and how this could possibly be given that this bug is obviously so severe that the product is unusable. in many cases what happened then is that Sun fixed the bug before the release - a bug which was actually found by some enterprise user who deployed "free" OOo and paid a consultant to file the bug in IssueZilla and then make a noise about it, without paying any developer to actually fix the bug. -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubs
[board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Michael, thanks for your feedback. On 25/02/2022 10:22, Michael Meeks wrote: On 23/02/2022 16:01, Paolo Vecchi wrote: Thanks to your comments I started writing a more structured proposal Thanks for doing that that - it helps. There are some good things about this proposal that are reasonable. I did my best to create a proposal that will allow TDF, the wider community and the various ecosystems to grow in an independent and meritocratic way. You can find the draft which starts outlining various concepts and lists some of the issues we have to address here: https://nextcloud.documentfoundation.org/s/fM8pCesPnF2JjN4 It's a bit sad it is a PDF, and without any heading numbering, so rather hard to interact with; an ODT that allowed comments / patching would be better. Instead I'll quote the text from the document as if you've mailed it here to comment on it. Until we have a Decidim instance running where we can test the best ways to collect feedback from the community, the mailing list seems to be the best way to collect and summarise the comments. I think my biggest concern is ultimately around managing the process of who decides what TDF should invest in - this is potentially extremely contentious and emotive over time, as are all ~zero sum resource decisions. Your proposal has: > The focus of the in-house developers will be set on specific areas > suggested for them by TDF’s team in consultation with the ESC and, > in case of unresolved conflicts, the board." Our current tendering process is open to everyone to make suggestions (although estimation bandwidth has to be provided by the ESC). It is ultimately approved (with the input of the ESC) by the elected board. I strongly prefer an open process like this that includes the community and is accountable to them. Of course it's great to have more input from the staff on priority areas - but I hope they're already well connected to the tendering process and the ESC. TDF's team is already participating to ESC meetings and with dedicated internal developers participating to those meetings they will add a different point of view to issues resolution and will be able to move faster on focus areas or small bugs, as they won't need to go through the tendering process, while at the same time verifying with ESC eventual overlaps. Many members of the ESC are employed by commercial contributors, are involved in proposing tenders to the board and are actually working on them when they win the bid so it will be easy to understand what overlaps and what doesn't. In contrast - the huge advantage of mentoring as an approach is that whomever wants to work on something gets help in proportion to their ability. That tends to solve the problem of working out what to do fairly - while giving some ability to steer via the creation of easy-hacks in specific areas etc. IMHO it isn't "in contrast", it's in addition to what is being done by TDF presently. As written in reply to Michael Weghorn: "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." Then I have a few other points: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? Looking at the raw data on the dashboard I wanted to understand a bit more about the trends and the composition of code contributors macro categories. The why is in the document: "Differentiating the type of committers is important as TDF’s developers will in general bring benefits to all but in some situations might be seen as being in competition against the commercial contributors so we need to evaluate what effect they may have on their business models while allowing TDF to grow." As you have noticed I took "the top 10 contributors over the past 5 full years" as it's the period when contributors numbers start to stabilise. The macro categories can be easily worked out but here they are: Commercial contributors: * Collabora * CIB->Allotropia Corporate contributors: * RedHat * Assigned (a bit of a mix but volumes don't change much the result) * NISZ * SIL * Munich Volunteers: * Unknown (no official affiliation) and TDF own contributions. I believe lots should be done to see if the "unknown" category could be better understood and find out how we can help groups of contributors in that macro category but that's something I still have to work as a separate project with the help of the team. > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > deve
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
On 24/02/2022 15:56, Paolo Vecchi wrote: On 24/02/2022 13:42, Michael Weghorn wrote: 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. Agreed. once they are settled and productive we should consider fulfilling our mission for users I think arguing that our mission requires us to do something or other in app-stores is controversial, particularly for a fee: The proposal draft says: > As determined in the past months TDF has in-house competences that > would allow us to start publishing LibreOffice Community in the > Windows and Apple app stores at a nominal price. Even if it is the right thing to do - and I think strategically it is an important move to consider how the project gets income in this way I would not say that: The topic isn't that controversial as it has been discussed at length in public and within the board. discussing something at length normally is a good sign of it being somewhat controversial =) Last I heard there was still a significant push from some to make all software free of price in every forum. > 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, I expect that all proposals here take into account the bigger picture of delivering improvements for LibreOffice; the differences being mostly over structure, control, jurisdiction etc. > there are still 2 proposals for business entities that would do just > that and the members of the ecosystem are perfectly fine with it. So - I see no necessity to make the proposal more controversial than it needs to be, by pre-deciding that TDF should employ resources to be focused on this: which could be seen to prejudice this decision in line with your preference. I would recommend removing that piece. Anyhow - otherwise, as I've said - modulo some deep concerns over decision making on how the new staff are deployed, and this unnecessary angle, I'm mildly supportive (for what it is worth). Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Re: Draft document for TDF in-house developers proposal
On 23/02/2022 16:01, Paolo Vecchi wrote: Thanks to your comments I started writing a more structured proposal Thanks for doing that that - it helps. There are some good things about this proposal that are reasonable. You can find the draft which starts outlining various concepts and lists some of the issues we have to address here: https://nextcloud.documentfoundation.org/s/fM8pCesPnF2JjN4 It's a bit sad it is a PDF, and without any heading numbering, so rather hard to interact with; an ODT that allowed comments / patching would be better. Instead I'll quote the text from the document as if you've mailed it here to comment on it. I think my biggest concern is ultimately around managing the process of who decides what TDF should invest in - this is potentially extremely contentious and emotive over time, as are all ~zero sum resource decisions. Your proposal has: > The focus of the in-house developers will be set on specific areas > suggested for them by TDF’s team in consultation with the ESC and, > in case of unresolved conflicts, the board." Our current tendering process is open to everyone to make suggestions (although estimation bandwidth has to be provided by the ESC). It is ultimately approved (with the input of the ESC) by the elected board. I strongly prefer an open process like this that includes the community and is accountable to them. Of course it's great to have more input from the staff on priority areas - but I hope they're already well connected to the tendering process and the ESC. In contrast - the huge advantage of mentoring as an approach is that whomever wants to work on something gets help in proportion to their ability. That tends to solve the problem of working out what to do fairly - while giving some ability to steer via the creation of easy-hacks in specific areas etc. Then I have a few other points: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > development and will help with the on-boarding of new external > commercial, corporate and volunteer contributors. Why do you believe that in-house developers (vs. say mentors) will help with on-boarding new contributors if that is not their focus? My suspicion is that mentoring is hard and "doing it yourself" is superficially easy in the short term. > TDF could start with posting for job positions where experience in > a11y, RTL, CJK, CTL are to be considered desired skills to see > if we can already find specialists in areas that have been neglected > for a while This is at least a realistic approach if these are the areas to invest in - then hiring for a specific skill-set looks reasonably achievable. > There are many small bugs or small features that, if developed by > tendering the project, could cost as much as the yearly salary of a > good developer if adding together the effort of creating the > tender, the actual cost of the development and the verification of > the deliverables Clearly for small tasks - the costs and overhead of the tendering process are (apparently) grossly excessive. Why this is quite so bad is unclear to me (having not been involved) - the tenders often arrive pre-written by the community; the estimation is not done by TDF, only deciding on bids & procuring, but the flow seems very high latency and burdensome somehow. Perhaps with a more technical board this term that is easier to fix. > Commercial contributors confirm that tenders issued by TDF form a > negligible part of their income Collabora publishes numbers on this at the conference each year - between 0% and 5% of income depending; but still, 5% is not insignificant. > and the quantity of bugs, features and updates that may require > tendering or paid for services by the commercial contributors is > still so vast that it will not affect noticeably their income While it is true that there may be an inexhaustible amount of work and TDF will never reduce that by doing some of it, I'm not sure that is really relevant. Tendering has been used by TDF to help stimulate, diversify and sustain the commercial ecosystem around LibreOffice since the beginning. TDF has a fairly fixed amount of cash - if there is less of that to spend, that will have a non-trivial impact. Worse than that though is the possible for TDF to significantly harm the market for bug-fixing far in excess of any work it can do - by creating the idea that there is a "free" way to have issues addressed through political machination at TDF. That needs extremely careful framing and communication
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.2.2022 10.29, Paolo Vecchi wrote: Hi Ilmari, thanks for the feedback. On 25/02/2022 09:06, Ilmari Lauhakangas wrote: Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area. Ilmari Is the whole Interoperability area that is well looked after or just MSO? Any other file formats that need to be improved? I was also looking at https://www.documentliberation.org and wondering if that would/should be part of the interoperability area that needs more attention. Probably some non-MSO formats would fit the category of not being very active, but I don't perceive them as a high priority area based on what users talk about. Ilmari -- 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
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Ilmari, thanks for the feedback. On 25/02/2022 09:06, Ilmari Lauhakangas wrote: Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area. Ilmari Is the whole Interoperability area that is well looked after or just MSO? Any other file formats that need to be improved? I was also looking at https://www.documentliberation.org and wondering if that would/should be part of the interoperability area that needs more attention. Ciao Paolo -- 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
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.2.2022 3.43, Thorsten Behrens wrote: Michael Weghorn wrote: 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. Certainly! There is certainly enough work to engage a multitude of developers in this area (and others). My thought was that - other than other topics mentioned - it generally seems to be less of a "niche" area in which there is generally little interest from others at the moment. Indeed. The other areas both have a lot of bugs, and almost no fixing activity. For interop, there's a lot of bug filing (i.e. community/user interest), but also a lot of bug fixing going on. The query from Michael currently shows 1973 open, vs. 3055 fixed. So I agree that beyond the ESC-ranked focus projects, it appears no intervention from TDF is currently necessary there. Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area. Ilmari -- 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
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
Hi *, Michael Weghorn wrote: > > > 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. > > Certainly! There is certainly enough work to engage a multitude of > developers in this area (and others). My thought was that - other than other > topics mentioned - it generally seems to be less of a "niche" area in which > there is generally little interest from others at the moment. > Indeed. The other areas both have a lot of bugs, and almost no fixing activity. For interop, there's a lot of bug filing (i.e. community/user interest), but also a lot of bug fixing going on. The query from Michael currently shows 1973 open, vs. 3055 fixed. So I agree that beyond the ESC-ranked focus projects, it appears no intervention from TDF is currently necessary there. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Paolo, thanks for your reply and additional explanations! On 24/02/2022 16.56, Paolo Vecchi wrote: 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. That sounds reasonable. 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. The ranking was actually for bugs that are already in either LO Bugzilla or NVDA's Github issue tracker. For the LO Bugzilla, this was a subset of the bugs *directly or indirectly* blocking the general a11y meta bug tdf#101912 that I mentioned in my previous email. [1] More exactly, it were the tickets set as *directly* blocking for the Windows-specific a11y meta bug tdf#60251, the general a11y meta bug tdf#101912 or the sidebar a11y meta bug tdf#103440; Bugzilla query: [2] (Note how the first link contains direct and indirect dependencies, while the second doesn't, so the second is a subset of the first one.) For NVDA's issue tracker, it were those bugs that have a LibreOffice/OpenOffice-related tag/label. Many issues have been reported in both issue trackers and the table maps those to each other. 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." Yes, that's what my "which is also explicitly listed as a goal" was referring to (but which maybe wasn't really clear in my email), and I think that's definitely an important aspect. And from what I understood, this also seemed to be uncontroversial in the BoD meeting about the topic. 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. That sounds very good to me. 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. Thanks for the explanation. My main concern was that "trying to do too many things at the same time" would potentially make finding a consensus harder. 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. Certainly! There is certainly enough work to engage a multitude of developers in this area (and others). My thought was that - other than other topics mentioned - it generally seems to be less of a "niche" area in which there is generally little interest fro
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
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 sh
[board-discuss] Re: Draft document for TDF in-house developers proposal
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
