Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v St 16. 02. 2022 v 15:04 +0100: > Is the "plan" a bit clearer for you now? Thank you, sounds much more positive this way. I'd still call it more an "outline" than a "plan", but I can see potential for the development mentoring in that too, so I can imagine we can agree something great for TDF together as the Board. > I'll find the time to collate together the feedback received by many > that help in completing the plan. The devil is always in the detail, but I'm all ears & patient too, please do take your time - I'm really looking forward to the plan. Again - thank you! All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, On 16/02/2022 14:34, Jan Holesovsky wrote: In other words, my view is that the "let's first hire 2 developers, and then see" approach is irresponsible, and we should have a plan first. I would agree with you if that were the case. The bullet points of the proposal already presented some reasons and started delineating a plan for it, many contributions to the conversation added to that plan more details. Email threads show that concepts may be difficult to follow but if you read through the emails you would notice that I proposed that the team and the suitable developers will start shaping what we could be focus on from the beginning. As already said, if we find an excellent a11y developer and one that has already got experience in fixing bugs in some unloved areas then the initial choices would be already made for us. If we only find "generic" C++ developers then naturally we'll have to train them in specific areas which the team will identify. Naturally, as said in this thread, the developers need to be initially quite flexible and learn to cover different areas including QA and mentorship. While the team adjust and we discover specific preferences for those developers then they could focus in an area more than others so that they can express their full potential. Is the "plan" a bit clearer for you now? I'll find the time to collate together the feedback received by many that help in completing the plan. Just give me a bit of time this is an activity I do by donating my time to TDF without expecting an economical return so I have to tend to other things as well. Ciao Paolo -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v St 16. 02. 2022 v 11:16 +0100: > It would be great if members of the board of directors, with their > TDF > hat on, would explain clearly why they seem to be opposed to > employing > in-house developers. I have never said I am opposed (and never said I'm supportive) to employing in-house developers, because I don't have enough information to make an informed decision yet. I have said two things: * I'd prefer hiring development mentors, rather than developers, because I am convinced that that is the best way how to scale as an organization responsible for the source code, and I see less potential problems with that * I am unhappy how the proposal to hire developers was and is being pushed, with lots of wishful thinking, and on the other hand without outlining potential problems, without proper discussion of the pro's & con's of this or other solutions, and without outlining details of tasking and management of the developers. In other words, my view is that the "let's first hire 2 developers, and then see" approach is irresponsible, and we should have a plan first. That is why I am so grateful to those who have constructively contributed to the debate, and particularly to those who have added their thoughts as answers or responses to my questions! All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, On 16/02/2022 09:52, Jan Holesovsky wrote: Hi Paolo, Paolo Vecchi píše v Út 15. 02. 2022 v 17:09 +0100: And to conclude: the easiest way to convince me (and likely others) on the board that a proposal is a good idea - is to make your case properly with a well-researched writeup. Could you please forward to me the well researched write-up used to employ the new mentor so that I can use that as a template? The difference is that we already have a mentor (actually several mentors in several areas), while you suggest a strategic decision - We recently employed only 1 mentor. No one else has been employed in that specific role. Are you able to forward to me the document where the case has been presented "with a well-researched writeup"? which in my view deserves research, consideration from multiple views, listening to others & consensus. We did the research in public, we had mostly 2 views, some have been listening to others and it would be great to recognise that there is a consensus that in-house developers are a desirable outcome which brings benefits to all. It is sometimes not clear to me if the undefined objections to enabling TDF to be a more active contributors in areas not well covered by others are coming from members of TDF's board of directors or representatives of "the industry" which sells LibreOffice development services. It would be great if members of the board of directors, with their TDF hat on, would explain clearly why they seem to be opposed to employing in-house developers. All the best, Kendy Ciao Paolo -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v Út 15. 02. 2022 v 17:09 +0100: > > And to conclude: the easiest way to convince me (and likely others) > > on > > the board that a proposal is a good idea - is to make your case > > properly with a well-researched writeup. > > Could you please forward to me the well researched write-up used to > employ the new mentor so that I can use that as a template? The difference is that we already have a mentor (actually several mentors in several areas), while you suggest a strategic decision - which in my view deserves research, consideration from multiple views, listening to others & consensus. All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On Tue, 2022-02-15 at 12:47 +0100, Paolo Vecchi wrote: > Hi Caolán, > > thanks for your feedback. > > On 14/02/2022 21:49, Caolán McNamara wrote: > > I think at least some of the push back is less against the concept > > that TDF should hire developers and more that it's a clearer path > > to start with some specific problems and then what options could > > solve them and hiring can be an option on that decision tree. It's > > a rare dev that has skills in multiple appstores, mentoring, qa, > > a11y, CTL, CJK and bugfixing in the various quite diverse > > components. > > Keep in mind that the point of the proposal was to get feedback from > the community and the team which seems to confirm that it is > desirable to have in-house developers to take care of certain areas. > > Now that we know we want in-house developers, the team and the > interviews will help in determining which areas we can start > covering. It does still feel somewhat cart before horse in the sense that it starts with a premise that hiring developers is the best solution and then backfills it with the problems to solve. And I can understand reluctance to go straight to that conclusion without stepping through it starting from some specific priority problem areas to make sure funds are distributed as wisely as possible to get the most tangible reward. -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi all, On 15/02/2022 15:50, Thorsten Behrens wrote: Hi *, Cor Nouws wrote: Paolo Vecchi wrote on 15/02/2022 12:47: Now that we know we want in-house developers, the team and the ... It is recognized that in-house developers (...) may be a (partial) solution some of the issues we face. Yeah it is a bit annoying, having to repeatedly state this is an ongoing process. I feel it's a bit like saying we need a marketing plan and somebody complaining that that's not good as it maybe only a partial solution of the issues we face. Well, now you have a marketing plan and some of the issues are being sorted. We face many more issues and a couple of developers will start easing some of them but once again it's a good step in the right direction. Then we'll deal also with the rest. From the board call minutes just posted: + Proposal: discuss more, decide with strategy workshop? (Lothar) + could be interesting (Paolo) + a consensus from one side brilliant idea to have it + other side seems like its a better idea for the ecosystem to do that A "consensus from one side" is not a consensus, and not a decision. The wider community and our own team seems to indicate that employing developers is actually a good idea. Even within the budget another member of the board proposed a new employee dedicated to QA so it seems like the need is there and I'm sure that 2 developers dedicating some of their time helping in QA and agreeing with the team which bugs should be fixed would help in speeding up things for both tasks. Currently, both the old and the new board are ranking all budget proposals. We will see what comes out top, if there's budget for it, and how the board & TDF can then execute on those items we want to do. So it seems like you are totally ignoring the feedback from the team and the community as you keep want to rank a strategic decision like any tender. We know that the budget is there and that we can move forward. The fact that you want to put them in a ranking sheet seems to show that you haven't yet understood the proposal from a strategic point of view. And to conclude: the easiest way to convince me (and likely others) on the board that a proposal is a good idea - is to make your case properly with a well-researched writeup. Could you please forward to me the well researched write-up used to employ the new mentor so that I can use that as a template? Repeatedly claiming that all is clear, and why haven't we hired yet - is not convincing, to say the least. It is clear that we should employ developers but the details as explained in a few emails well be worked out with the team. Cheers, -- Thorsten Ciao Paolo -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi *, Cor Nouws wrote: > Paolo Vecchi wrote on 15/02/2022 12:47: > > > Now that we know we want in-house developers, the team and the ... > > It is recognized that in-house developers (...) may be a (partial) solution > some of the issues we face. > Yeah it is a bit annoying, having to repeatedly state this is an ongoing process. From the board call minutes just posted: + Proposal: discuss more, decide with strategy workshop? (Lothar) + could be interesting (Paolo) + a consensus from one side brilliant idea to have it + other side seems like its a better idea for the ecosystem to do that A "consensus from one side" is not a consensus, and not a decision. Currently, both the old and the new board are ranking all budget proposals. We will see what comes out top, if there's budget for it, and how the board & TDF can then execute on those items we want to do. And to conclude: the easiest way to convince me (and likely others) on the board that a proposal is a good idea - is to make your case properly with a well-researched writeup. Repeatedly claiming that all is clear, and why haven't we hired yet - is not convincing, to say the least. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Paolo Vecchi wrote on 15/02/2022 12:47: Now that we know we want in-house developers, the team and the ... It is recognized that in-house developers (...) may be a (partial) solution some of the issues we face. So I really look forward to the proposal you are working on that will address all the ideas and questions we saw in the discussion so far. 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
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Caolán, thanks for your feedback. On 14/02/2022 21:49, Caolán McNamara wrote: I think at least some of the push back is less against the concept that TDF should hire developers and more that it's a clearer path to start with some specific problems and then what options could solve them and hiring can be an option on that decision tree. It's a rare dev that has skills in multiple appstores, mentoring, qa, a11y, CTL, CJK and bugfixing in the various quite diverse components. Keep in mind that the point of the proposal was to get feedback from the community and the team which seems to confirm that it is desirable to have in-house developers to take care of certain areas. Now that we know we want in-house developers, the team and the interviews will help in determining which areas we can start covering. We have already identified that we have the in-house skills to manage the app stores but internal developers, together with external expertise if necessary, can help in adapting LibreOffice packages to deal with the eventual changes and issues that may arise when app store rules change. If interviews show that there are interested parties that are also specialised, or have a good grasp, of a11y, RTL and CJK then that will help in determine what they will cover otherwise we will need to see if they can and are interested in growing their skills in those areas. Developers could also dedicate part of their time in QA and mentoring while helping in validating tenders and their deliverables so I'm sure that nobody will get bored and everyone over time will have the opportunity to show in which areas they perform best. At this stage there are many areas that need to be covered and everyone in the team has demonstrated to be capable in adapting and perform many different tasks. The same adaptability will be, at least at the beginning, appreciated from the new members of the team. Over time funds coming from app stores and donations will allow us to further grow our team and will allow members of the team to focus more in specific areas if they wish. I'm fully aware that this is not the way established development/consulting companies work but TDF isn't one and it needs to build up its internal skills organically for the reasons explained in this thread. Ciao Paolo -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On Mon, 2022-02-14 at 18:12 +0100, Paolo Vecchi wrote: > Hi Kendy, > > On 14/02/2022 16:42, Jan Holesovsky wrote: > > > > > > In my world [regardless of the hat], a constructive debate is much > > easier over a document collecting: > > > > * the problem statement & the need > > * the pros & cons of various solutions > > * the proposal & conclusion > > Something like this?: > > * As shown by Italo's slides at FOSDEM again and by others, TDF > is not contributing as much as it could > * Up to now no strategic decisions have been taken to make TDF a > more regular and active code contributor > * Members of the ecosystem and others also suggested that we > should spend more money in development > * Bugs, a11y issues and features can be harder to taken care of > by volunteers and are not always addressed by the ecosystem > * We need to build up internal skills and development > capabilities to speed up innovation > * Lack of suppliers diversification, mostly 2 at present, is a > suboptimal situation for TDF, LibreOffice and its community > * Internal developers can grow to cover areas like mentoring and > QA while also helping with new contributors support > * TDF needs to expand its internal capacity to deal with > publishing in app stores directly and manage variable levels of > complexity due to ever changing rules > * Some proposed projects could be developed internally instead > of outsourcing them, which helps to grow in-house skills and capacity > to address our donors needs > * Potential App Stores revenues may allow for more developers > and to invest in developing other projects > * Our development mentor together with the team should propose > to the BoD projects for internal development > * While internal projects may cover different areas tenders and > ESC proposals will be also evaluated to avoid effort duplication > * This is not "just" a new project, it's an essential and > strategical move for TDF to grow further in its second decade which > widens the horizon for new visions and opportunities to do more and > even better things for LibreOffice and our community > * Funds are available for at least 2 developers allowing us to > start employing them straight away > * Next steps: create and publish the job offers for developers > and on-board them ASAP > > This has allowed to get a feel for the proposal, which seems very > positive, and now we'll be working on the details but at least it > showed that the community thinks we are moving in the right > direction. > > Then should the new developers invest 30% of their time in QA, 50% > in bug fixing and 20% in reviewing tenders and deliverables? > That's something we should see with the team as they have a very > good feel of what is going on. I think at least some of the push back is less against the concept that TDF should hire developers and more that it's a clearer path to start with some specific problems and then what options could solve them and hiring can be an option on that decision tree. It's a rare dev that has skills in multiple appstores, mentoring, qa, a11y, CTL, CJK and bugfixing in the various quite diverse components. -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, On 14/02/2022 16:42, Jan Holesovsky wrote: Hi Andreas, Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100: but maybe it would be great, if you could stop to pick on someone. It seemed your only intention on this topic is to control (with your non-TDF-hat on) everything. That is not a cooperative behavior. I've told it in the public part of the Board meeting on Friday, and will repeat it again: I am very sad that this whole discussion started framed as (let me paraphrase) "TDF will hire 2 developers, it is all done deal, there are no problems" [in concrete words "Funds are available for at least 2 developers allowing us to start employing them straight away; Next steps: create and publish the job offers for developers and on-board them ASAP"]. The proposal is a proposal not a contract. This is extremely unhelpful, as it totally dismisses views of others. There was no full agreement of this in the Board, no plan, no prioritization against other budget items and no consideration if this is the best way how to improve the situation - so please don't be surprised it lead to a challenging discussion. I do understand your point of view as I found it "very regrettable" that my views and proposals that were clearly stated in my candidacy statement got dismissed by others. I did have a conversation with the board trying to explain that this is a strategic decision that shouldn't be seen as a ranked project but my point of view was totally ignored by those that didn't care much about respecting others' views. Then others tried to dismiss my proposal trying to frame it as us vs others political battle: ' + very regrettable (Simon) + to frame this as partisan - one side vs. another + particularly when one side is "the industry"' That last line is also very regrettable as "the industry" (2 suppliers very well represented in the board) seem to be more equal than others and if we don't listen to "the industry" very bad things will happen. I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and others (I'm sure I forgot some, sorry about that) for their patience & helpful input, and I do hope we will move to a more constructive, concrete debate. It has been a very constructive debate which seems to show that most have understood that my proposal has many ramifications that will help TDF in moving forward in a positive way. The good thing is that even the members of the ecosystem seem to have seen the proposal as beneficial for all the parties involved. We should have more of these debates in public so that the team and the community can tell us if we are going in the right direction. In my world [regardless of the hat], a constructive debate is much easier over a document collecting: * the problem statement & the need * the pros & cons of various solutions * the proposal & conclusion Something like this?: * As shown by Italo's slides at FOSDEM again and by others, TDF is not contributing as much as it could * Up to now no strategic decisions have been taken to make TDF a more regular and active code contributor * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation * Lack of suppliers diversification, mostly 2 at present, is a suboptimal situation for TDF, LibreOffice and its community * Internal developers can grow to cover areas like mentoring and QA while also helping with new contributors support * TDF needs to expand its internal capacity to deal with publishing in app stores directly and manage variable levels of complexity due to ever changing rules * Some proposed projects could be developed internally instead of outsourcing them, which helps to grow in-house skills and capacity to address our donors needs * Potential App Stores revenues may allow for more developers and to invest in developing other projects * Our development mentor together with the team should propose to the BoD projects for internal development * While internal projects may cover different areas tenders and ESC proposals will be also evaluated to avoid effort duplication * This is not "just" a new project, it's an essential and strategical move for TDF to grow further in its second decade which widens the horizon for new visions and opportunities to do more and even better things for LibreOffice and our community * Funds are available for at least 2 developers allowing us to start employing them straight away * Next steps: create and publish the job offers for developers and on-board them ASAP This has allowed to get a feel for the proposal, which seems
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, On 14/02/2022 14:40, Jan Holesovsky wrote: Hi Paolo, Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100: As I started the proposal I'm very happy to work with Sophie and Hossein to complement the proposal with the useful feedback we received in this thread. Perfect, I am looking forward to an ODT that we can then collectively redline as the Board, to form a proposal based on consensus! Thanks, I'm looking forward to having the board agreeing that it's the best strategic move for TDF to start employing internal developers. I'm sure that if all board members think about the best for TDF we will reach an unanimous consensus on it very quickly. As to working with Sophie & Hossein - are you about to politely ask them to work on that as volunteers (as I've asked Michael W. - Michael, once again thank you for your input & answers!), As to working with Sophie and Hossein I have publicly asked members of TDF's team to work together on an opportunity that affects them, as we are talking about new colleagues, and on which they can share their thoughts and experience as they are working in many areas and are able to identify the best ways to get the new developers to be most effective within the team and for the good of our wider community. True that I could have added the word "please", I was probably too excited to start working with members of the team and totally forgot, but I'm sure both Sophie and Hossein didn't get offended by it. or are you about to ask your fellow Board members & Florian to dedicate some of their work time (ie. donation money) to work on the proposal? Our team must invest its time for the best of TDF, LibreOffice and the wider community and that's what our donors want. Keep also in mind most volunteers are also donors as time for most of us has a value. I'm generally selling my time at X amount per hour/day so I'm donating that value to TDF with the only scope of doing my best for TDF, LibreOffice and the community as I passionately believe on the project and the good that it's doing all over the world without expecting any economical return. Naturally there is a limit on the amount of time I can donate as while it makes me happy to be doing my best for TDF and the community, like anyone else, I have to dedicate my time also in doing things that pay the bills. Others may be able to invest as much time as it is necessary as anyway some outcomes may be also quite beneficial for their own companies, that may create a bit of an imbalance in the decision making process. Thank you! Thank you for understanding how much many are donating in time and money to TDF and that we need to move forward to show them their donations really matter to us. All the best, Kendy Ciao Paolo -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, all, Am 14.02.22 um 16:42 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100: but maybe it would be great, if you could stop to pick on someone. It seemed your only intention on this topic is to control (with your non-TDF-hat on) everything. That is not a cooperative behavior. I've told it in the public part of the Board meeting on Friday, and will repeat it again: I am very sad that this whole discussion started framed as (let me paraphrase) "TDF will hire 2 developers, it is all done deal, there are no problems" [in concrete words "Funds are available for at least 2 developers allowing us to start employing them straight away; Next steps: create and publish the job offers for developers and on-board them ASAP"]. but that gave TDF the option to work on tasks which are important for the LibO user and for the market strength of the LibreOffice community edition. This is extremely unhelpful, as it totally dismisses views of others. There was no full agreement of this in the Board, no plan, no prioritization against other budget items and no consideration if this is the best way how to improve the situation - so please don't be surprised it lead to a challenging discussion. I'm sorry but it seemed the challenging discussion is done only by one person. And don't be surprised that there is not always full consensus in a decision process. At some point you have to decide with the majority of votes to avoid endless discussions. I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and others (I'm sure I forgot some, sorry about that) for their patience & helpful input, and I do hope we will move to a more constructive, concrete debate. Maybe you made excessive demands on their patience and self-perception. In my world [regardless of the hat], a constructive debate is much easier over a document collecting: I think it is (nearly?) impossible to take part in a debate, if you have a CoI (because you sit on two sites of a table). Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Andreas, Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100: > but maybe it would be great, if you could stop to pick on someone. > > It seemed your only intention on this topic is to control (with your > non-TDF-hat on) everything. > > That is not a cooperative behavior. I've told it in the public part of the Board meeting on Friday, and will repeat it again: I am very sad that this whole discussion started framed as (let me paraphrase) "TDF will hire 2 developers, it is all done deal, there are no problems" [in concrete words "Funds are available for at least 2 developers allowing us to start employing them straight away; Next steps: create and publish the job offers for developers and on-board them ASAP"]. This is extremely unhelpful, as it totally dismisses views of others. There was no full agreement of this in the Board, no plan, no prioritization against other budget items and no consideration if this is the best way how to improve the situation - so please don't be surprised it lead to a challenging discussion. I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and others (I'm sure I forgot some, sorry about that) for their patience & helpful input, and I do hope we will move to a more constructive, concrete debate. In my world [regardless of the hat], a constructive debate is much easier over a document collecting: * the problem statement & the need * the pros & cons of various solutions * the proposal & conclusion That with change tracking (redlining) turned on & possibility to comment - so that it is possible to finalize it to a form that is acceptable for all involved: in other words, to form a consensus. So - I am really looking forward to such a document! Actually I'd be happy to start it myself, if that helped the situation; and would ask people to volunteer to work with me on that - but not sure it is a good idea just now. All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Ilmari, Thank you for your answers, lots of great stuff! Just two notes: Ilmari Lauhakangas píše v So 12. 02. 2022 v 23:30 +0200: > > * How to make sure they don't compete with other open source > > projects, > >or the ecosystem companies? > > Trust the more experienced staff members to know this distinction > when > it comes to areas of focus. I fear it shouldn't be about trust only :-) - so I'm looking forward to the Paolo's promised document, I hope it will cover it some way too. > > * How to avoid growing a group-think in the internal developers > >group that there is no need for the ecosystem companies, or even > >for the community as a whole? [As explained elsewhere; as much > > as > >it sounds strange - TDF is a subset of the community, not the > > other > >way around.] > > By regular brainwashing sessions conducted by me (I am well-known for > my > free advertising of the ecosystem companies before and after my > hiring > at TDF). Love this one! :-D - thank you! All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, I'm not Paolo, but maybe it would be great, if you could stop to pick on someone. It seemed your only intention on this topic is to control (with your non-TDF-hat on) everything. That is not a cooperative behavior. Regards, Andreas Am 14.02.22 um 14:40 schrieb Jan Holesovsky: Hi Paolo, Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100: As I started the proposal I'm very happy to work with Sophie and Hossein to complement the proposal with the useful feedback we received in this thread. Perfect, I am looking forward to an ODT that we can then collectively redline as the Board, to form a proposal based on consensus! As to working with Sophie & Hossein - are you about to politely ask them to work on that as volunteers (as I've asked Michael W. - Michael, once again thank you for your input & answers!), or are you about to ask your fellow Board members & Florian to dedicate some of their work time (ie. donation money) to work on the proposal? Thank you! All the best, Kendy -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100: > As I started the proposal I'm very happy to work with Sophie and > Hossein > to complement the proposal with the useful feedback we received in > this > thread. Perfect, I am looking forward to an ODT that we can then collectively redline as the Board, to form a proposal based on consensus! As to working with Sophie & Hossein - are you about to politely ask them to work on that as volunteers (as I've asked Michael W. - Michael, once again thank you for your input & answers!), or are you about to ask your fellow Board members & Florian to dedicate some of their work time (ie. donation money) to work on the proposal? Thank you! All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Ilmari, thanks a lot for your contributions. In the next few days I'll prepare a document with Sophie and Hossein combining also your comments so that we can start moving forward with a concrete plan and a job description. I see that you are joining Heiko in proposing to employ a web developer. I suppose that your proposal isn't seen by anyone as being problematic so if the team with the ED create a job description we could get also that approved fairly quickly. Ciao Paolo On 12/02/2022 22:30, Ilmari Lauhakangas wrote: On 10.2.2022 23.46, Jan Holesovsky wrote: Hi Italo, Italo Vignoli píše v Čt 10. 02. 2022 v 18:28 +0100: I would have applauded a reaction to the message that has opened this thread which was integrating the proposal with some additional thoughts and suggestions, to specify which could be the areas where a developer hired by TDF could work for the common benefit of the project. I see, thank you for the explanation! I have expressed elsewhere in this thread that I am a proponent of hiring more development mentors rather than generic developers; so it is hard for me to get excited about this proposal. Also I forgot to answer Heiko elsewhere that his idea of graphics designer / website developer in one person sounds reasonably positive to me. Having said that, maybe we can get a bit more constructive even in this discussion about hypothetical possibility of hiring generic developers; so what about this: Michael, please - would you be willing to further your (and Sophie's) idea in form of a document that can be discussed as a whole, particularly how the details together fit the TDF mission? I myself would be interested in the following questions; do you think you can cover them some way, please? I'm not Michael, but thanks for the helpful points. * How to frame the hiring process - where developers should have a say in it, without being accused of CoI? I would frame the role description to begin with as focusing on underloved areas and thus ecosystem company reps would be very welcome to participate in the interviews etc. As long as they refrain from poaching in the middle of the process ;) * How to make it quick, so that the potential hires are still available once TDF decides for this or that candidate? Maybe time the interviews for a season of the year that we know is not rush hour for all of us. * How to get the developers up-to-speed or mentor them once they are hired? I suppose if the current mentoring capability is not sufficient for specific core hacking deep dives, contracting mentoring from domain experts in the commercial ecosystem would be an option. * Also how to task them, how to day-to-day manage them, and how to make sure they are progressing at a reasonable pace? I will go into the content of the imagined tasks at the end. Regarding smooth progress, one of my self-assumed responsibilities is to protect experts from noise and more trivial or repetitive things, so I think fostering this sort of a supportive environment would help. * What to do if they get stuck, and there is nobody in the community who can help them? Park the stuck task and work on something else. * How to detect they are not performing, and just consume the donors' money? The current way the directors monitor staff seems enough for this role as well. * How to make sure they don't compete with other open source projects, or the ecosystem companies? Trust the more experienced staff members to know this distinction when it comes to areas of focus. * How to make sure they are not misused by (any, not only ecosystem) companies to fix bugs for them or for their customers? [Particularly companies disguised by @gmail or so addresses in bugzilla.] > * On the other hand - how to make it possible to cherry-pick fixes or features into the release branches of ecosystem companies without the risk of being accused of misusing the previous point? This kind of activity seems detectable by staff, but the previous answer also applies. If some traditionally underloved area would suddenly get regular bug reports, it would in itself draw a lot of attention. Yet, instead of defining some sanctions, I think it would be best to not stress about edge cases no one can fully control, if the end result is shipping good stuff to everyone anyway. * Should there be a mechanism for the ecosystem companies to flag a bug "this is what I'm working on for a customer - please don't touch"? I'm not sure if it's needed, but this mechanism could be a string placed in the Whiteboard field of a report. * With my pet idea of development mentors rather than generic developers in mind - should they be mentoring too, and if yes, how to prioritize vs. the actual development? Yes, they should be. The prioritisation arises organically: 1. there is the huge mass of people I mentor 2. not all of the people from point 1 even
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On 10.2.2022 23.46, Jan Holesovsky wrote: Hi Italo, Italo Vignoli píše v Čt 10. 02. 2022 v 18:28 +0100: I would have applauded a reaction to the message that has opened this thread which was integrating the proposal with some additional thoughts and suggestions, to specify which could be the areas where a developer hired by TDF could work for the common benefit of the project. I see, thank you for the explanation! I have expressed elsewhere in this thread that I am a proponent of hiring more development mentors rather than generic developers; so it is hard for me to get excited about this proposal. Also I forgot to answer Heiko elsewhere that his idea of graphics designer / website developer in one person sounds reasonably positive to me. Having said that, maybe we can get a bit more constructive even in this discussion about hypothetical possibility of hiring generic developers; so what about this: Michael, please - would you be willing to further your (and Sophie's) idea in form of a document that can be discussed as a whole, particularly how the details together fit the TDF mission? I myself would be interested in the following questions; do you think you can cover them some way, please? I'm not Michael, but thanks for the helpful points. * How to frame the hiring process - where developers should have a say in it, without being accused of CoI? I would frame the role description to begin with as focusing on underloved areas and thus ecosystem company reps would be very welcome to participate in the interviews etc. As long as they refrain from poaching in the middle of the process ;) * How to make it quick, so that the potential hires are still available once TDF decides for this or that candidate? Maybe time the interviews for a season of the year that we know is not rush hour for all of us. * How to get the developers up-to-speed or mentor them once they are hired? I suppose if the current mentoring capability is not sufficient for specific core hacking deep dives, contracting mentoring from domain experts in the commercial ecosystem would be an option. * Also how to task them, how to day-to-day manage them, and how to make sure they are progressing at a reasonable pace? I will go into the content of the imagined tasks at the end. Regarding smooth progress, one of my self-assumed responsibilities is to protect experts from noise and more trivial or repetitive things, so I think fostering this sort of a supportive environment would help. * What to do if they get stuck, and there is nobody in the community who can help them? Park the stuck task and work on something else. * How to detect they are not performing, and just consume the donors' money? The current way the directors monitor staff seems enough for this role as well. * How to make sure they don't compete with other open source projects, or the ecosystem companies? Trust the more experienced staff members to know this distinction when it comes to areas of focus. * How to make sure they are not misused by (any, not only ecosystem) companies to fix bugs for them or for their customers? [Particularly companies disguised by @gmail or so addresses in bugzilla.] > * On the other hand - how to make it possible to cherry-pick fixes or features into the release branches of ecosystem companies without the risk of being accused of misusing the previous point? This kind of activity seems detectable by staff, but the previous answer also applies. If some traditionally underloved area would suddenly get regular bug reports, it would in itself draw a lot of attention. Yet, instead of defining some sanctions, I think it would be best to not stress about edge cases no one can fully control, if the end result is shipping good stuff to everyone anyway. * Should there be a mechanism for the ecosystem companies to flag a bug "this is what I'm working on for a customer - please don't touch"? I'm not sure if it's needed, but this mechanism could be a string placed in the Whiteboard field of a report. * With my pet idea of development mentors rather than generic developers in mind - should they be mentoring too, and if yes, how to prioritize vs. the actual development? Yes, they should be. The prioritisation arises organically: 1. there is the huge mass of people I mentor 2. not all of the people from point 1 even reach the level where Hossein becomes their primary mentor 3. for the core hacking level, the hypothetical staff devs could share the mentoring responsibility, optimally on the areas they themselves are working on * How to avoid growing a group-think in the internal developers group that there is no need for the ecosystem companies, or even for the community as a whole? [As explained elsewhere; as much as it sounds strange - TDF is a subset of the community, not the other way around.] By regular brainwashing sessions
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, On 10/02/2022 22:46, Jan Holesovsky wrote: Michael, please - would you be willing to further your (and Sophie's) idea in form of a document that can be discussed as a whole, particularly how the details together fit the TDF mission? I think Michael provided very relevant feedback in many areas (thank you!) but it would be unfair to impose on him to also start writing documents which should be prepared with the help of our team. As I started the proposal I'm very happy to work with Sophie and Hossein to complement the proposal with the useful feedback we received in this thread. Ciao Paolo -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, thanks for sharing your thoughts/concerns! On 10/02/2022 22.46, Jan Holesovsky wrote: I have expressed elsewhere in this thread that I am a proponent of hiring more development mentors rather than generic developers; so it is hard for me to get excited about this proposal. Also I forgot to answer Heiko elsewhere that his idea of graphics designer / website developer in one person sounds reasonably positive to me. I believe that not being excited about the idea is totally valid. Let me explicitly mention that I'm also open to other suggestions and how they would help to move forward with the issues that were brought up. As mentioned in my reply to Michael [1] however, I'm currently not so convinced whether "plain" development mentors would have the same chance of providing success when it comes to progress in *specific* areas (which does not at all mean I'm against having more mentors in general). Having said that, maybe we can get a bit more constructive even in this discussion about hypothetical possibility of hiring generic developers; so what about this: Michael, please - would you be willing to further your (and Sophie's) idea in form of a document that can be discussed as a whole, particularly how the details together fit the TDF mission? While I wouldn't say I came up with the general idea, I'm happy to contribute my thoughts in case the decision in today's BoD meeting is that it's worth having such a document for further discussion. I don't think I'll be able to do that just by myself (and there are certainly people who know better "how TDF works"), but I'm definitely willing to be part of a group that creates such a document. I'll reply with some first thoughts to your questions below for further discussion without claiming those are "the ultimate answers". In any case, I'm happy to learn and hear other opinions. I myself would be interested in the following questions; do you think you can cover them some way, please? * How to frame the hiring process - where developers should have a say in it, without being accused of CoI? I'm not familiar with the TDF hiring process. Is it so that the BoD is involved here and ultimately takes the decision? If so, I don't see any lack of competent developers in the new BoD to cover that perspective. :-) In my previous email I wrote that I personally wouldn't assume a CoI in case the tasks of TDF developers were set accordingly, and it definitely sounds reasonably to me for all BoD members to have a say. I'm not too familiar with the CoI policy, but as I understand it, the remaining BoD decides whether or not a CoI exists for a specific member. So would that point be addressed in case all BoD members agreed that all BoD members can have a say in the vote? (Whether or not all BoD members agree here is obviously a question I cannot answer.) * How to make it quick, so that the potential hires are still available once TDF decides for this or that candidate? I'm not familiar with the TDF hiring process, but I would assume the answer here should be unspecific to the specific role of the person being hired and would arise just the same in case of hiring more development mentors instead. * How to get the developers up-to-speed or mentor them once they are hired? That probably depends on whether the hired developers are completely new to the project or have participated previously. In general, I'd go with the established approach that is used for non-TDF contributors as well (have them learn by doing). * Also how to task them, how to day-to-day manage them, [...] (splitting this here, second part of the sentence below) That's up to discussion, my initial idea outlined in my previous email [2] would be to involve ESC and/or BoD when it comes to larger topics to be worked on. I personally wouldn't see a need to control every single small item that they work on but give them some "freedom" to work on what they identify along the way as they work on larger topics. But if there's a concern that would be problematic, more micro-management from BoD (or some representative that has been assigned by the BoD to take care) would of course be possible as well (like assigning specific Bugzilla tickets to work on or first discuss the thoughts they come up while doing their other work). [...] and how to make sure they are progressing at a reasonable pace? * What to do if they get stuck, and there is nobody in the community who can help them? I think those are questions that every developer is facing. My personal perception is that developers are working together well and there has so far basically always been help from others when somebody asks for specific help at a certain point (via developer mailing list or IRC). * How to detect they are not performing, and just consume the donors' money?z As above for the hiring process: I think the BoD has experienced developers
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
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:
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi all! On Thu, Feb 10, 2022 at 4:45 PM sophi wrote: > > Their is even no written proposal at the moment, but only a discussion > on the pros and cons and what it could bring to the project. But it > seems impossible to discuss because the ecosystem companies won't allow it. > And yet it seems here we are discussing it! It's fun to do things that aren't allowed :-) The OP did indeed not make a written proposal, but there still* a *Board Motion to hire two developers despite this. Personally (and I don't work for any "ecosystem company" or TDF or belong to a local group) I don't feel either the OP's proposal or any other response commenting on it here represents me. I volunteered here because I think LibreOffice is massively important to the free/open source software movement, as well as to the freedom of citizens globally, including especially non-English-speaking and differently-able people. I want to see TDF spend its money in the service of that global movement to the maximum extent it has allowed itself to in its bylaws. I especially believe TDF needs to act to allow individuals to avoid the need to use centralised services for making, reading and sharing documents of all kinds. Right now TDF is not doing so, despite being given millions of euros by end-users. My concern is thus not with the desire to spend donated money on donor problems - we should do more of it, and better, and not let any corporate interest stop us. My concern is with accepting as agreed the proposal that TDF should hire developers and afterwards address what they would do, how and under whose supervision. I can see *significant* risks from doing so and I do not want in any way to endorse that premature proposal. So sure, let's have a pros and cons discussion. I have already chipped in positively elsewhere and look forward to being able to amplify other positive ideas, But first let's take the political and premature motion off the table so that no-one feels their contribution is either supporting or opposing it. It has led to an essential discussion becoming yet another divisive fight and that's got to stop. Cheers! Simon -- *Simon Phipps* *TDF Trustee*
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On 10.02.2022 17:56, Michael Weghorn wrote: Hi Michael (W.), I absolutely agree with what you wrote. My deepest thank you for being so open-minded! On 10/02/2022 16.31, Italo Vignoli wrote: On 2/10/22 13:36, Michael Weghorn wrote: Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. Totally agree. 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. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering. I totally agree, extending that process to cover significant tasks that internal developers would work on may be a solution. Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions). To double-check nobody is "secretly" working on that as well or is planning to do so, discussing/mentioning larger items first certainly won't hurt. (But that doesn't only apply for work done by TDF developers; e.g. the weekly ESC call already has a "What’s cooking" section where that would fit well.) I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone. Definitely! Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...] At least from my developer's perspective, I totally agree with what you wrote. Thanks again, Marina -- Marina Latini IRC: deneb_alpha on LiberaChat -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On 10.02.2022 17:53, Michael Meeks wrote: Hi Michael, all, It seems reasonable to explore what people should be hired to do - before hiring them =) That has the benefit of working out what skills are needed in the job advert and/or interview process for example. The 'discussion' here - I would not see as blocked, but problematic see later. I don't think the discussion is even at this point. Reading the messages I can only see some board members just questioning every single commas used by the others, fighting in public without even realising that all this drama is only bringing away community members interested to share more ideas and proposals for solving this deadlock we are experiencing. 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. ...and again, it's not always "Collabora vs others" discussion. There's a discussion, not even a concrete proposal on how TDF could contribute more code, there are other opinions shared and an attempt to really act like a community that tries to shape its own projects. Can we stop to reduce every possible discussion to the "ecosystem vs all the others"? We are all part of the same project, many of us were part of it from day 0, some officially, others unofficially, but we were all there. Can we stop to act like kids and try to really cooperate like adults? As for finding new board members on the list to express a view you feel represents you: these long threads packed with trolling and misrepresentation on board-discuss are not a great way to interact I suspect. Why would a new board member want to engage in them while they find their feet ? Lets not be quick to preemptively despair of sensible decision making. This way to act is not only affecting the board members. It has a negative impact on the full community and on all the potential new contributors that are just scared away by all those dramas. 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. ...talking about trolling, I was indeed missing yet another comment against the CoI policy. Cheers, Marina -- Marina Latini IRC: deneb_alpha on LiberaChat -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On 10.02.2022 17:44, sophi wrote: Hi Sophie, hi all, And I feel the same. Hiring developers is not the only way forward, it's one of them. We, as members, knows the ecosystem companies have needs and I (for myself) understand perfectly the market pressure. But here, as a member of TDF, we contribute with the ecosystem companies, not for them. I agree. you simply wrote what I was thinking to add. thanks. Their is even no written proposal at the moment, but only a discussion on the pros and cons and what it could bring to the project. But it seems impossible to discuss because the ecosystem companies won't allow it. I'm sorry, I already wrote in a previous thread that TDF has failed to have a balanced position during the pandemic, caring of the charitable part of its duty, I hope we will not continue in that way because, again as a member, this is not how I feel represented. ...and I fully agree again. Cheers, Marina -- Marina Latini IRC: deneb_alpha on LiberaChat -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On 2/10/22 17:27, Jan Holesovsky wrote: Yes, but it looks like the discussion is blocked one step before reaching a consensus on this very simple point. If the discussion stays as such, I have to say that I don't feel I am represented - as a TDF Member - by any member of the just elected board of directors (of course, those who have expressed their opinions). This is very sad to hear :-( I am afraid this is a product of the unilateral & vigorous presentation of hiring developers as the only way forward, regardless of what the ecosystem companies have to say. I disagree. This is the result of BoD members pointing fingers to each other without even trying to start a discussion and reach consensus. I would have applauded a reaction to the message that has opened this thread which was integrating the proposal with some additional thoughts and suggestions, to specify which could be the areas where a developer hired by TDF could work for the common benefit of the project. Sorry, but I haven't seen anything like this so far. -- Italo Vignoli - LibreOffice Marketing & PR mobile/signal +39.348.5653829 - email it...@libreoffice.org GPG Key ID - 0xAAB8D5C0 DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0 -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
On 2/10/22 17:53, Michael Meeks wrote: It would be deeply unfortunate if the above was read as questioning the legitimacy and composition of the new board - and that before they have been seated and/or taken a single decision. It would be good to clarify that reading. I am not questioning the legitimacy and composition of the board, I am questioning the behaviour of its members. -- Italo Vignoli - LibreOffice Marketing & PR mobile/signal +39.348.5653829 - email it...@libreoffice.org GPG Key ID - 0xAAB8D5C0 DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0 -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, thanks for your reply. On 10/02/2022 16.31, Italo Vignoli wrote: On 2/10/22 13:36, Michael Weghorn wrote: Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. Totally agree. 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. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering. I totally agree, extending that process to cover significant tasks that internal developers would work on may be a solution. Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions). To double-check nobody is "secretly" working on that as well or is planning to do so, discussing/mentioning larger items first certainly won't hurt. (But that doesn't only apply for work done by TDF developers; e.g. the weekly ESC call already has a "What’s cooking" section where that would fit well.) I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone. Definitely! Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...] At least from my developer's perspective, I totally agree with what you wrote. 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
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, On 10/02/2022 15:31, Italo Vignoli wrote: On 2/10/22 13:36, Michael Weghorn wrote: I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be. Yes, but it looks like the discussion is blocked one step before reaching a consensus on this very simple point. It seems reasonable to explore what people should be hired to do - before hiring them =) That has the benefit of working out what skills are needed in the job advert and/or interview process for example. The 'discussion' here - I would not see as blocked, but problematic see later. 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. 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. 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. 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). If the discussion stays as such, I have to say that I don't feel I am represented - as a TDF Member - by any member of the just elected board of directors (of course, those who have expressed their opinions). and: > Of course, given my complete lack of understanding of development, is > too easy to find a technical angle to disprove what I just wrote, but > it would also be disproving what many of the contributors - the > community - think, and this would confirm my personal belief that > TDF BoD does not represent the community as a whole, but only a > portion of it. It would be deeply unfortunate if the above was read as questioning the legitimacy and composition of the new board - and that before they have been seated and/or taken a single decision. It would be good to clarify that reading. I would note that everyone who stood for the board was elected - and perhaps acknowledging the complexity of what might look like simple decisions from the outside - is real & not imaginary. I wish them the best as they try to find the local maxima in some multi-dimensional problem space. As for finding new board members on the list to express a view you feel represents you: these long threads packed with trolling and misrepresentation on board-discuss are not a great way to interact I suspect. Why would a new board member want to engage in them while they find their feet ? Lets not be quick to preemptively despair of sensible decision making. 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. 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:
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, Le 10/02/2022 à 17:27, Jan Holesovsky a écrit : Hi Italo, Italo Vignoli píše v Čt 10. 02. 2022 v 16:31 +0100: Yes, but it looks like the discussion is blocked one step before reaching a consensus on this very simple point. If the discussion stays as such, I have to say that I don't feel I am represented - as a TDF Member - by any member of the just elected board of directors (of course, those who have expressed their opinions). This is very sad to hear :-( I am afraid this is a product of the unilateral & vigorous presentation of hiring developers as the only way forward, regardless of what the ecosystem companies have to say. And I feel the same. Hiring developers is not the only way forward, it's one of them. We, as members, knows the ecosystem companies have needs and I (for myself) understand perfectly the market pressure. But here, as a member of TDF, we contribute with the ecosystem companies, not for them. Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. Totally agree. 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. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering. If assurances like these were part of the proposal, I am sure it would be much easier to discuss - at least for me personally. Thank you for pointing this out! Their is even no written proposal at the moment, but only a discussion on the pros and cons and what it could bring to the project. But it seems impossible to discuss because the ecosystem companies won't allow it. I'm sorry, I already wrote in a previous thread that TDF has failed to have a balanced position during the pandemic, caring of the charitable part of its duty, I hope we will not continue in that way because, again as a member, this is not how I feel represented. And also Michael (W.) - thank you for your great summary! yes, thanks Michael to have broaden my proposal and my ideas. Cheers Sophie -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, Italo Vignoli píše v Čt 10. 02. 2022 v 16:31 +0100: > Yes, but it looks like the discussion is blocked one step before > reaching a consensus on this very simple point. If the discussion > stays > as such, I have to say that I don't feel I am represented - as a TDF > Member - by any member of the just elected board of directors (of > course, those who have expressed their opinions). This is very sad to hear :-( I am afraid this is a product of the unilateral & vigorous presentation of hiring developers as the only way forward, regardless of what the ecosystem companies have to say. > > Of course, in case the main intention were for TDF to provide more > > business-like services (like an LTS version or creating an > > impression of > > "donate a certain amount of money and your pet bug will be fixed"), > > I > > see very well how that might interfere significantly with the > > business > > model of ecosystem companies. > > Totally agree. 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. AFAIK, major development activities are scrutinized by > both > bodies, as they are ranked in order of importance, suggested, > approved > and transformed to tenders, or not considered for tendering. If assurances like these were part of the proposal, I am sure it would be much easier to discuss - at least for me personally. Thank you for pointing this out! And also Michael (W.) - thank you for your great summary! All the best, Kendy -- 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Thank you for your support Michael! I confirm that my proposal does not contemplate at all offering LTS version or any other services in exchange for donations. Ciao Paolo On 10/02/2022 13:36, Michael Weghorn wrote: Hi all, On 08/02/2022 17.01, sophi wrote: Le 07/02/2022 à 19:16, Paolo Vecchi a écrit : * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too. That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use. That sounds like a good approach to me, in particular for areas where there's currently no specific interest from ecosystem companies or volunteers and that are unsuitable for tenders, but considered important for the community. I would see that in line with how TDF already employs non-developer staff to take care of other important aspects not (sufficiently) covered by other contributors. I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be. If larger topics that TDF-internal developers were to work on were first agreed on in the bodies where ecosystem companies are present as well (like ESC and/or the board), my expectation would be that the development work from different sides should work together nicely, rather than creating any kind of destructive competition. (Ecosystem company products profit from contributions made to LibreOffice as well, and having a better overall product should in my opinion also increase the range of potentially interested customers in general.) Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. 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. However, I must admit I don't know the ecosystem company perspective first-hand, so would be interested in learning more about specific concerns. Best regards, Michael -- Paolo Vecchi - Deputy 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: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi all, On 08/02/2022 17.01, sophi wrote: Le 07/02/2022 à 19:16, Paolo Vecchi a écrit : * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too. That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use. That sounds like a good approach to me, in particular for areas where there's currently no specific interest from ecosystem companies or volunteers and that are unsuitable for tenders, but considered important for the community. I would see that in line with how TDF already employs non-developer staff to take care of other important aspects not (sufficiently) covered by other contributors. I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be. If larger topics that TDF-internal developers were to work on were first agreed on in the bodies where ecosystem companies are present as well (like ESC and/or the board), my expectation would be that the development work from different sides should work together nicely, rather than creating any kind of destructive competition. (Ecosystem company products profit from contributions made to LibreOffice as well, and having a better overall product should in my opinion also increase the range of potentially interested customers in general.) Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. 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. However, I must admit I don't know the ecosystem company perspective first-hand, so would be interested in learning more about specific concerns. 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
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Thank you Sophie! Having also feedback from the members of the Team is very important for me as you'll have to deal with your new colleagues as well ;-) Please do reach out saying openly what you see right and/or wrong in this proposal so that you can help the board in making the right decision for TDF and our community. Ciao Paolo On 08/02/2022 17:01, sophi wrote: Hi Paolo, Le 07/02/2022 à 19:16, Paolo Vecchi a écrit : Hi all, Thanks for discussing your proposal here. Just wanted to add a few words within your lines, so jumping here: [...] * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too. That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use. Cheers Sophie -- Paolo Vecchi - Deputy 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
[board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
El 7/2/22 a las 15:16, Paolo Vecchi escribió: Hi all, many of you voted for me as you wanted me to promote and achieve the goals set in my candidacy statement: https://listarchives.documentfoundation.org/www/board-discuss/2021/msg00279.html Point 1 is what leads me once again to share with the community my intention to push forward point 3 and 4 so that you can all provide your objective contributions to help me and the rest of the board in doing the right things for TDF and our community. The following is a summary of the points that support the need and the feasibility of the proposal: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs * As shown by Italo's slides at FOSDEM again and by others, TDF is not contributing as much as it could * Up to now no strategic decisions have been taken to make TDF a more regular and active code contributor * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation * Lack of suppliers diversification, mostly 2 at present, is a suboptimal situation for TDF, LibreOffice and its community * Internal developers can grow to cover areas like mentoring and QA while also helping with new contributors support * TDF needs to expand its internal capacity to deal with publishing in app stores directly and manage variable levels of complexity due to ever changing rules * Some proposed projects could be developed internally instead of outsourcing them, which helps to grow in-house skills and capacity to address our donors needs * Potential App Stores revenues may allow for more developers and to invest in developing other projects * Our development mentor together with the team should propose to the BoD projects for internal development * While internal projects may cover different areas tenders and ESC proposals will be also evaluated to avoid effort duplication * This is not "just" a new project, it's an essential and strategical move for TDF to grow further in its second decade which widens the horizon for new visions and opportunities to do more and even better things for LibreOffice and our community * Funds are available for at least 2 developers allowing us to start employing them straight away * Next steps: create and publish the job offers for developers and on-board them ASAP The proposal will be publicly discussed this Friday 11 of February so I'm looking forward to your constructive feedback to make it a better proposal for all. In the meantime I hope you appreciated my efforts in relation to point 6: https://blog.documentfoundation.org/blog/2022/01/27/bug-bounties-finding-and-fixing-security-holes-with-european-commission-funds/ Ciao Paolo -- Paolo Vecchi - Deputy 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 I believe that the arguments in favor are way more than enough. TDF must set the course and have its own weight within ESC. In addition, projects that are not attractive to the valuable members of the ecosystem could be divided into smaller parts and dealt with within the foundation itself. We must avoid reaching an instance similar to LOOL, where one part simply closed the door. In that sense, influence and/or dependence on just two providers is not in the best interest of the foundation itself or the LibreOffice Community.
[board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Le 07/02/2022 à 19:16, Paolo Vecchi a écrit : Hi all, Thanks for discussing your proposal here. Just wanted to add a few words within your lines, so jumping here: [...] * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too. That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use. Cheers Sophie -- 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
