Re: [Meta] Discussing in board-discuss [ was: Re: [board-discuss] Merged proposal for in-house developers at TDF]
Hi Simon, On 12/06/2022 12:42, Simon Phipps wrote: Please note that I have (intentionally) refrained from responding to earlier messages. But no-one (including you) was addressing the repeated negative framing of Andreas' many e-mails so I offered a contribution from experience to balance it. Some actually addressed Andreas' emails and understood the requests for a positive change for TDF. If others wants to look away when there are criticisms they a free to do it but then they shouldn't negatively affect those that wants to fix issues. > By entering into a dialogue. By hearing and evolving compromises with > other members through selecting positive elements of their > contributions. I'd generally agree, but what I can read from the thread is that some discussions and objections are less likely to be acknowledged and recognized, and taken as a basis to work on a positive compromise, mostly because that is not coming from a long-time contributor. Doing everything by text-only for two years has been extremely toxic. The positive side of it is that we now have clear records in email threads that allowed us to pinpoint issues that then had to be dealt with. That's not the case for Andreas, who you are confirming he is akin to the Foundation since a lot of time. Andreas was one of the founding generation of TDF so has been involved in the project for a long time, yes. He contributed great work on infrastructure and deserves credit for it. He was unhappy when TDF migrated from Plone and I believe felt insulted by that step because his work was lost, which we regretted. I do understand that frustration, and have experienced it myself. Regardless of the reasons behind his will to participate to discussions I found Andreas' contributions very useful. Sometimes he's very direct but we have to accept that there are different communication styles and that we can't block or refer to the CoC people only because they say something that might not conform with our own ideas. I hope that more community members will find the courage to speak out if they see that there are issues that need to be dealt with. > How should members voice their concerns when they see entryists harming > the project and old unsettled grudges being repeatedly raised regardless > of how they are answered? Let's start by acknowledging that if there are objections and they are even consistently confirmed from long relationships and from short ones, possibly something to discuss is there. Absolutely right. My original message however was to indicate that there is a very old problem that has not been "let go" and which newcomers might not recognise, and its repetition should probably not be heavily weighted as an indicator of the validity of the concerns today. Old problems should not be "let go" they should be evaluated objectively and addressed. If Andreas was demanding that we re-implemented his Plone infrastructure I'll be one of those saying that it's probably better if he "let go" but as far as I can see Andreas comments had nothing to do with it and all to do with improving our processes, increasing transparency and adding bits of information that are difficult to source as they might be spread in old email archives. I've been on the receiving side of Andreas' effort to keep an eye on board's decisions pointing out potential issues and I've actually appreciated that. I think there should be more people like him to keep the board in check and make sure we don't get too complacent or reliant on a narrative coming from only one source. Cheers Simon -- *Simon Phipps* /TDF Trustee/ Ciao Paolo -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details:https://www.documentfoundation.org/imprint
Re: [Meta] Discussing in board-discuss [ was: Re: [board-discuss] Merged proposal for in-house developers at TDF]
Hi Emiliano, On Sun, Jun 12, 2022 at 11:03 AM Emiliano Vavassori < syntaxerror...@libreoffice.org> wrote: > Hi Simon, > > Il 12/06/22 11:17, Simon Phipps ha scritto: > > I am sorry you do not find this helpful, but being > > aware of the true history of the project (especially at a time when > > there are voices trying to reframe history) is very important and > > refusing to do so may lead to incorrect assumptions and the acceptance > > of untrue framing. > > I didn't say I found it useless, I said it wouldn't really still help > with moving the general balance of the discussion towards a positive > outcome, which was the main objections to Andreas' mails. > Please note that I have (intentionally) refrained from responding to earlier messages. But no-one (including you) was addressing the repeated negative framing of Andreas' many e-mails so I offered a contribution from experience to balance it. > By entering into a dialogue. By hearing and evolving compromises with > > other members through selecting positive elements of their > > contributions. > > I'd generally agree, but what I can read from the thread is that some > discussions and objections are less likely to be acknowledged and > recognized, and taken as a basis to work on a positive compromise, > mostly because that is not coming from a long-time contributor. I don't think it's primarily about the length of time contributing. I'd suggest the problem is more that the decision-making style at TDF is a friend-to-friend collaboration that, when there is a strong disagreement, reverts to face-to-face discussion. We have discovered over the long term that text-only discussions lead to both misunderstandings and escalation that are (usually) resolved when people meet in person. We have also discovered that text disagreements discourage participation by people who are either conflict-averse or concerned the argument is public and permanently recorded. Attempts to do what we always did in the past when there were disagreements - stop arguing in e-mail and have a phone call, and have a face-to-face if that doesn't work - have been blocked. I am really pleased to see the Board has been gathered in-person this weekend and sincerely hope you've all been able to devise ways to work together. Doing everything by text-only for two years has been extremely toxic. > That's > not the case for Andreas, who you are confirming he is akin to the > Foundation since a lot of time. > Andreas was one of the founding generation of TDF so has been involved in the project for a long time, yes. He contributed great work on infrastructure and deserves credit for it. He was unhappy when TDF migrated from Plone and I believe felt insulted by that step because his work was lost, which we regretted. I do understand that frustration, and have experienced it myself. > How should members voice their concerns when they see entryists harming > > the project and old unsettled grudges being repeatedly raised regardless > > of how they are answered? > > Let's start by acknowledging that if there are objections and they are > even consistently confirmed from long relationships and from short ones, > possibly something to discuss is there. Absolutely right. My original message however was to indicate that there is a very old problem that has not been "let go" and which newcomers might not recognise, and its repetition should probably not be heavily weighted as an indicator of the validity of the concerns today. Cheers Simon -- *Simon Phipps* *TDF Trustee*
Re: [Meta] Discussing in board-discuss [ was: Re: [board-discuss] Merged proposal for in-house developers at TDF]
+1 Paolo On 12/06/2022 12:03, Emiliano Vavassori wrote: Hi Simon, Il 12/06/22 11:17, Simon Phipps ha scritto: They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities. That is still setting a (partial, angled) framing of the situation (as Andreas was doing, to some extent). What still worries me is that said frictions are still there after a lot of years and weren't solved, and honestly I don't buy it is a constellation of personal issues, rather than a misunderstanding on how effectively implement the shared goals we all should have. I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing. I didn't say I found it useless, I said it wouldn't really still help with moving the general balance of the discussion towards a positive outcome, which was the main objections to Andreas' mails. By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions. I'd generally agree, but what I can read from the thread is that some discussions and objections are less likely to be acknowledged and recognized, and taken as a basis to work on a positive compromise, mostly because that is not coming from a long-time contributor. That's not the case for Andreas, who you are confirming he is akin to the Foundation since a lot of time. How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered? Let's start by acknowledging that if there are objections and they are even consistently confirmed from long relationships and from short ones, possibly something to discuss is there. Cheers, -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- 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] Merged proposal for in-house developers at TDF
Hi Simon, On 12/06/2022 11:17, Simon Phipps wrote: Hi Emilliano, On Sun, Jun 12, 2022 at 9:31 AM Emiliano Vavassori wrote: Hi Simon, Il 11/06/22 20:02, Simon Phipps ha scritto: > I will remind you > that you started this negative approach about how TDF is acting > illegally when you and I were on the Board together last decade. I'm honestly struggling to see how your comments can be thought as positive. They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities. I was a newcomer in 2020 and I didn't get much help from you or other old members of the board in understanding the past to take decision for the future of TDF. I had to spend a lot of time reading lots of minutes of past meetings and keep asking difficult questions to get to the point where I could clearly see that some decisions being passed down to us (eg TDC) had issues that haven't been considered. It is good to have people like Andreas that point out issues that should be evaluated by newcomers before they fall into a group thinking situation that does not help with addressing problems and moving forward. I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing. It is important to learn about the past to plan for the future. Discovering some details that are not widely publicised helps in fixing some issues that have been overlooked. TDF is not just a small group of friends developing LibreOffice any more, it is now a larger organisation that needs to apply some rules so that it creates a level playing field for everyone that wants to contribute in many ways, not only with code which for some seems to be the only measure if some people or organisations are more equal than others. And how should users and members should voice their unsettlement, without risking to be stopped at every corner and called out for violations of CoC. By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions. By collaborating together even when uncomfortable. By respecting the honest contributions of long-time contributors. This place is hardly a close venue. Compromises and unanimity in decisions would be great but are not always possible as some points of view are too far apart. Some cling very hard onto their acquired positions and it is very difficult and frustrating to get them to understand that times have changed and that is not only their code that makes TDF, our community and LibreOffice great for all. Even when compromises have been agreed some decide to walk away and not contribute back to a project like LOOL that isn't made up only by code but also by lots of contributions from the rest of our community. How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered? "Entryists" bring also fresher, different point of views and ask the questions that some don't want to hear. "Entryists" helped in stopping a project you promoted that would have been damaging for TDF and our community, "entryists" tried to bring clarity on what LOOL really was and found out that reality was different from what was promoted, "entryists" got finally a CoI Policy in place for the board and (IMHO) should implement it also for the ESC, "entryists" are still working on lots of other improvements that will help TDF serve better its community. So yes, "entryists" should look at both side of the arguments, dig deeper in their merits and then promote the required changes. I hope you noticed the usefulness of "entryists" and that you will help them with unbiased information in future instead of attacking them because they haven't conformed with your views. Sincerely, Simon -- *Simon Phipps* /TDF Trustee/ Ciao Paolo -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details:https://www.documentfoundation.org/imprint
[Meta] Discussing in board-discuss [ was: Re: [board-discuss] Merged proposal for in-house developers at TDF]
Hi Simon, Il 12/06/22 11:17, Simon Phipps ha scritto: They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities. That is still setting a (partial, angled) framing of the situation (as Andreas was doing, to some extent). What still worries me is that said frictions are still there after a lot of years and weren't solved, and honestly I don't buy it is a constellation of personal issues, rather than a misunderstanding on how effectively implement the shared goals we all should have. I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing. I didn't say I found it useless, I said it wouldn't really still help with moving the general balance of the discussion towards a positive outcome, which was the main objections to Andreas' mails. By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions. I'd generally agree, but what I can read from the thread is that some discussions and objections are less likely to be acknowledged and recognized, and taken as a basis to work on a positive compromise, mostly because that is not coming from a long-time contributor. That's not the case for Andreas, who you are confirming he is akin to the Foundation since a lot of time. How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered? Let's start by acknowledging that if there are objections and they are even consistently confirmed from long relationships and from short ones, possibly something to discuss is there. Cheers, -- Emiliano Vavassori syntaxerror...@libreoffice.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] Merged proposal for in-house developers at TDF
Hi Emilliano, On Sun, Jun 12, 2022 at 9:31 AM Emiliano Vavassori < syntaxerror...@libreoffice.org> wrote: > Hi Simon, > > Il 11/06/22 20:02, Simon Phipps ha scritto: > > I will remind you > > that you started this negative approach about how TDF is acting > > illegally when you and I were on the Board together last decade. > > I'm honestly struggling to see how your comments can be thought as > positive. > They are to help newcomers like you become aware that the complaints being made are not in fact new or related to the current situation but date back to a dispute that is many years old and still unresolved due to personal enmities. I am sorry you do not find this helpful, but being aware of the true history of the project (especially at a time when there are voices trying to reframe history) is very important and refusing to do so may lead to incorrect assumptions and the acceptance of untrue framing. > > And how should users and members should voice their unsettlement, > without risking to be stopped at every corner and called out for > violations of CoC. > By entering into a dialogue. By hearing and evolving compromises with other members through selecting positive elements of their contributions. By collaborating together even when uncomfortable. By respecting the honest contributions of long-time contributors. This place is hardly a close venue. How should members voice their concerns when they see entryists harming the project and old unsettled grudges being repeatedly raised regardless of how they are answered? Sincerely, Simon -- *Simon Phipps* *TDF Trustee*
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Simon, Il 11/06/22 20:02, Simon Phipps ha scritto: I will remind you that you started this negative approach about how TDF is acting illegally when you and I were on the Board together last decade. I'm honestly struggling to see how your comments can be thought as positive. And how should users and members should voice their unsettlement, without risking to be stopped at every corner and called out for violations of CoC. Regards, -- Emiliano Vavassori syntaxerror...@libreoffice.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] Merged proposal for in-house developers at TDF
Hi Andreas, On Sat, Jun 11, 2022 at 6:49 PM Andreas Mantke wrote: > But I'm tired to repeatedly try to explain things with the same result. > Otherwise that could be judged as a constant negative message by a > reader of this list. > Since I currently have no relevant affiliation to prevent me speaking up and given this reference to my earlier admonition, I will remind you that you started this negative approach about how TDF is acting illegally when you and I were on the Board together last decade. You repeatedly intervened at Board meetings with comments that the things the rest of the Board were discussing or deciding were in breach of the rules or the law. When asked to provide evidence to support your assertions, you never produced any, and when asked to propose alternative actions, you never did. Your actions seriously delayed the Board from taking necessary actions on behalf of the Foundation as they sought a consensus you repeatedly blocked. The Board at that time sought advice and found it had the discretion to take all the actions against which you were warning. The negative framing should have stopped then. Instead, despite leaving both the Board and the Foundation, you have continued to snipe from the sidelines at every opportunity, always critical and never building on the contributions of others. Again, I recommend you withdraw. Sincerely, Simon -- *Simon Phipps* *TDF Trustee*
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, Am 10.06.22 um 12:20 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Čt 09. 06. 2022 v 20:48 +0200: this confirms that TDF has payed a part of the Android and Online development from donation money. Interestingly, I don't recall any of the Collabora Productivity clients (even proprietary companies) ever complaining that the code Collabora develops for them end up in the open, as Free Software, and may be reused later to build new stuff on top of that, and that it may help other clients too. seemed it is really hard to understand the content of my message. ;-( But I'm tired to repeatedly try to explain things with the same result. Otherwise that could be judged as a constant negative message by a reader of this list. The donation money were used to develop Android editing. The fact that a small part of that work was later re-used for other developments is irrelevant, this his how Open Source and Free Software works. And I abstain from commenting this, because it seemed we don't share the same view about the behavior in question this topic. 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] Merged proposal for in-house developers at TDF
Hi Andreas, thanks again for providing a very good analysis of the issues which should be taken in consideration. Now that finally the objection about the "app stores" has been clarified as the board published the decision the are only a few differences left between my original proposal and this new one. 1) I don't think is a good idea to try to find senior developers willing to mentor as we have already to that are doing an excellent job and are still growing. The new in-house developers may not need to be senior as it's good for TDF to invest in new developers with good experience and allow them to grow with us together with our mentors, the rest of the team and the community. They'll probably grow to become mentors but that shouldn't be the focus now. 2) The new part related getting into long term contract with external provider is premature as we will see who we find, what experience they have and then decide if other experts are needed to help them grow or deal directly with some complex parts as anyway specified in my proposal. 3) During the past year we worked on what TDF can and cannot do as a foundation under German laws and we found that we can do a lot more than previously thought including employing developers. 4) The rest seems to be an effort to have members of TDF's team controlled by the ESC or to impose limitations suggested by commercial contributors. It is clear in many part of the text of the other proposal but this sentence makes things clear for all: "For avoidance of doubt, by no means the Targeted Developer or TDF leadership by tasking the Targeted Developer can overrule code-related decisions as decided by the ESC." This could have been tolerated if the ESC were a properly regulated committee with a CoI Policy and a clear history of being a neutral ground for all. IMHO recent interventions during ESC meetings disqualifies this committee from imposing decisions on any TDF body and employees. Other elements like contracts with third parties, impositions from third party companies not to work on or something similar to LOOL or not to work on possible future projects that could be interesting for third party companies do not belong to a document related to employing developers. Those areas should be discussed publicly to create clear rules of engagement valid with any third party companies regardless if they are current or future contributors. In the upcoming version 2.2 of my proposal I've added a paragraph that explicitly excludes that the in-house employees should be bound by any decision from the ESC. I've read in full the other proposal and while, thanks to comments and suggestions, it seems to be converging back to my original proposal it still creates more issues than anything else. Now that my initial concerns about a "merged" version have been proven right it would be great to finalise the original proposal if anyone can provide more contributions. On 10/06/2022 20:13, Andreas Mantke wrote: Hi all, Am 10.06.22 um 12:03 schrieb Jan Holesovsky: Hi Michael, Thank you for the feedback! I've updated the document accordingly, see below: Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +: (...) Quoting from my previous email: (I think it definitely makes sense to get deeper into the topic and cooperate with other organizations and free software projects. I still think that the main focus should be to achieve practical improvements in LO. Depending on the target area, I can think of more or less way that this would naturally involve contributing to other free software projects etc, but - given limited resource - I personally wouldn't necessarily see contributing to other projects or doing research as a main goal by itself, at least not in the beginning.) After all, it seems to be a matter of setting priorities how TDF money is spent, and one can decide one way or the other. I can't judge how well each option fits with the "Development per se is not part of TDF mission" you mention, but to me, doing "development per se" doesn't seem to be less in line with the TDF mission than spending money on tenders, as was mentioned elsewhere in one of the threads already. I think, in the past, there used to be long discussions whether TDF can or cannot have developers; so my hope that framing that in a way that fits the mission by default can help here. For the moment, I've added the "Developers per se..." there, but I don't insist, can be further tweaked in whatever way needed, I think. The board spent a lot of donation money for the LibreOffice development (and other development tasks) during the last years. There is no difference between spending money for source code development and hiring in-house developers for doing such work. If spending donation money for the development tenders is compatible with the statutes and the charity status then there is no barrier for hiring developers. The latter is the better
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, Am 10.06.22 um 12:03 schrieb Jan Holesovsky: Hi Michael, Thank you for the feedback! I've updated the document accordingly, see below: Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +: (...) Quoting from my previous email: (I think it definitely makes sense to get deeper into the topic and cooperate with other organizations and free software projects. I still think that the main focus should be to achieve practical improvements in LO. Depending on the target area, I can think of more or less way that this would naturally involve contributing to other free software projects etc, but - given limited resource - I personally wouldn't necessarily see contributing to other projects or doing research as a main goal by itself, at least not in the beginning.) After all, it seems to be a matter of setting priorities how TDF money is spent, and one can decide one way or the other. I can't judge how well each option fits with the "Development per se is not part of TDF mission" you mention, but to me, doing "development per se" doesn't seem to be less in line with the TDF mission than spending money on tenders, as was mentioned elsewhere in one of the threads already. I think, in the past, there used to be long discussions whether TDF can or cannot have developers; so my hope that framing that in a way that fits the mission by default can help here. For the moment, I've added the "Developers per se..." there, but I don't insist, can be further tweaked in whatever way needed, I think. The board spent a lot of donation money for the LibreOffice development (and other development tasks) during the last years. There is no difference between spending money for source code development and hiring in-house developers for doing such work. If spending donation money for the development tenders is compatible with the statutes and the charity status then there is no barrier for hiring developers. The latter is the better choice because TDF get more impact on the development process and gain more in-house knowledge. This would also help TDF e.g. to more easily participate in the GSoC The hope is that there will be many applicants, and that we'll have the possibility to choose two. But if there is only one good candidate, I think we should not start another round of interviews until we evaluate the experience - because the process is expensive & time consuming. What about "... will not develop alternative implementations of Open Source projects actively maintained by LibreOffice volunteer or corporate contributors."? LOOL could be an example, but there is eg. the Kohei's mdds (that is essential for the Calc core), or Moggi's maintenance of cppunit - hosted on freedesktop, but using LibreOffice bugzilla for bugreports. That still seems a bit to be too generic to me. For the moment, I've at least adapted it to the above, but happy to go further there, if you can propose a wording please? Also I was thinking of something like "TDF in-house developers will encourage up-streaming in case their work ends up as a modification of an external LibreOffice project." (to target things like PDFium etc.) OK, I've added the explicit list as examples. it is not in the interest of TDF / LibreOffice community to exclude areas of development per se. If the LibreOffice community and the board thinks the development of a product, a module etc. is important and necessary for the future / the (further) growth of the program / the community it had to be able to point his development resources (in-house or else) into that direction. No commercial / free software company has the right to distract the foundation from doing that. Thus it is not appropriate to add such sentences to the proposal. And from my impression the 'merged proposal' is a paper to prune TDF's freedom and to support only commercial companies. But such a proposal is never in the best interest of the foundation and the board should abstain to vote for such a proposal. 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] Merged proposal for in-house developers at TDF
Hi Kendy, On 10/06/2022 12.03, Jan Holesovsky wrote: Thank you for the feedback! I've updated the document accordingly, see below: Thanks a lot! I'm not sure. It's still a bit unclear to me what "researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas" means in practice, s.a. questions in my previous emails. I see - so this is to make sure the work of the developers fits the charitable mission of TDF. I have the impression that my personal understanding/perspective of the job of a targeted developer is a bit different from the one outlined in your proposal, and more in line with Paolo's when there are no mentees in the developer's target areas. That would seem reasonable to me: * If there are mentees in the target area, mentoring is the primary focus (as outlined in your proposal). * However, if there are no mentees, it's the primary focus to do development in the target area. Thank you, I've added this as clarification. [...] I think, in the past, there used to be long discussions whether TDF can or cannot have developers; so my hope that framing that in a way that fits the mission by default can help here. For the moment, I've added the "Developers per se..." there, but I don't insist, can be further tweaked in whatever way needed, I think. Re-reading the sentence now with those changes in place, I'm wondering whether I just previously misunderstood what was meant: Is "researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas" actually the part that includes working on LibreOffice code? If so, the prioritization makes total sense to me as is. (I was previously assuming that this is yet another activity besides doing direct mentoring and the development task, something that would be done to have a larger "mentoring" share of some kind if there weren't "enough" mentees at hand, and I didn't really understand what that would be in practice, so wondering whether it would be justified to spend resources on that.) If it helps finding a consensus (minimize differences between the 2 proposals at hand), I wonder whether it would make sense to rephrase this, so that it becomes clear that having 2 would be preferred (and just employing one if only one suitable candidate shows up is the fallback), but for me personally, this explanation is enough and it doesn't seem to make any difference in practice. OK, I've changed the default to 2, fallback to 1; and added a note for the Board to decide when no suitable candidate is found. Thanks, looks good to me. What about "... will not develop alternative implementations of Open Source projects actively maintained by LibreOffice volunteer or corporate contributors."? LOOL could be an example, but there is eg. the Kohei's mdds (that is essential for the Calc core), or Moggi's maintenance of cppunit - hosted on freedesktop, but using LibreOffice bugzilla for bugreports. That still seems a bit to be too generic to me. For the moment, I've at least adapted it to the above, but happy to go further there, if you can propose a wording please? Looks better to me already. What I had in mind was an explicit list, something like: "TDF in-house developers will not compete with commercial contributors and will not develop alternative implementations of the following Open Source projects actively maintained by LibreOffice volunteer or corporate contributors: Collabora Online, mdds, cppunit" [add more here if more are an area of concern] Also I was thinking of something like "TDF in-house developers will encourage up-streaming in case their work ends up as a modification of an external LibreOffice project." (to target things like PDFium etc.) Sounds good. Thanks again, 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] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Čt 09. 06. 2022 v 20:48 +0200: > this confirms that TDF has payed a part of the Android and Online > development from donation money. Interestingly, I don't recall any of the Collabora Productivity clients (even proprietary companies) ever complaining that the code Collabora develops for them end up in the open, as Free Software, and may be reused later to build new stuff on top of that, and that it may help other clients too. The donation money were used to develop Android editing. The fact that a small part of that work was later re-used for other developments is irrelevant, this his how Open Source and Free Software works. > If I remember correctly I attended a presentation from Michael M. > about > a LibreOffice online pre alpha version at the conference in Paris > 2011. The prototype from 2011 was using a different approach (remote desktop in a browser) and no code from that approach was used in online.git. 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] Merged proposal for in-house developers at TDF
Hi Simon, Simon Phipps píše v Pá 03. 06. 2022 v 09:59 +0100: > On Fri, Jun 3, 2022 at 7:51 AM Ilmari Lauhakangas < > ilmari.lauhakan...@libreoffice.org> wrote: > > Tendering and in-house development are not interchangeable, but > > they are > > interlinked. Keep in mind that the in-house devs would participate > > in > > running tenders. > > Another valuable role for an in-house developer would be to manage a > more long-term relationship with specialist subcontractors, for > example a company with expertise in accessibility development. With a > longer-term expert subcontractor, TDF could then actually develop new > capabilities rather than simply fix bugs and stand still like AOO. By > adding to our list of approaches a managed but non-employee longer- > term relationship with outside firms that is not limited to a single > task, TDF would be able to both benefit from the flexibility of > tendering and also gain the benefit of long-term staffing. Thank you very much, I've added this paragraph as a new Focus area, and removed your comment that touched this area. 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] Merged proposal for in-house developers at TDF
Hi Michael, Thank you for the feedback! I've updated the document accordingly, see below: Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +: > > Please don't get me wrong - I believe the appstores is an important > > discussion, just don't want to block the hiring on that; as I think > > it > > is orthogonal to that. > > I used to agree here. > > In light of the recent BoD decision that TDF will publish LO in the > app > stores [1] however, I think it is fair to reconsider this, and > consider > development needed to keep LO in line with app store requirements as > a > potential target area for TDF-internal developers, unless that's > already > covered otherwise. [...] > In that regard, the "App stores management" section in Paolo's > updated > proposal (v2.1) looks reasonable to me at first sight. Makes sense, I've removed the deletion, the "App stores management" is back. > > Ah - it is the extension of the rationale how the development > > itself > > fits the TDF mission, ie. doesn't make that much sense without the > > previous paragraph that starts "Why is it important to major on > > mentoring". > > > > So how about: "Development per se is not part of TDF mission, but > > it is > > expected that while a mentor is unable to actively contribute to > > public > > and professional education for whatever reason (eg. absence of > > volunteers) that they will be researching and increasing their > > experience by contributing to new ways to advance the free software > > and > > standards in their particular Target Areas." > > > > Does it make more sense this way? > > I'm not sure. It's still a bit unclear to me what "researching and > increasing their experience by contributing to new ways to advance > the > free software and standards in their particular Target Areas" means > in > practice, s.a. questions in my previous emails. I see - so this is to make sure the work of the developers fits the charitable mission of TDF. > I have the impression that my personal understanding/perspective of > the > job of a targeted developer is a bit different from the one outlined > in > your proposal, and more in line with Paolo's when there are no > mentees > in the developer's target areas. > That would seem reasonable to me: > > * If there are mentees in the target area, mentoring is the primary > focus (as outlined in your proposal). > * However, if there are no mentees, it's the primary focus to do > development in the target area. Thank you, I've added this as clarification. > Quoting from my previous email: > > > (I think it definitely makes sense to get deeper into the topic and > > cooperate with other organizations and free software projects. > > I still think that the main focus should be to achieve practical > > improvements in LO. Depending on the target area, I can think of > > more or less way that this would naturally involve contributing to > > other free software projects etc, but - given limited resource - I > > personally wouldn't necessarily see contributing to other projects > > or doing research as a main goal by itself, at least not in the > > beginning.) > > After all, it seems to be a matter of setting priorities how TDF > money > is spent, and one can decide one way or the other. > I can't judge how well each option fits with the "Development per se > is > not part of TDF mission" you mention, but to me, doing "development > per > se" doesn't seem to be less in line with the TDF mission than > spending > money on tenders, as was mentioned elsewhere in one of the threads > already. I think, in the past, there used to be long discussions whether TDF can or cannot have developers; so my hope that framing that in a way that fits the mission by default can help here. For the moment, I've added the "Developers per se..." there, but I don't insist, can be further tweaked in whatever way needed, I think. > > Indeed, I should clarify this; I think changing "Overlaps or > > prioritisations that find ..." to "Technical decisions that > > find..." > > could do? > > Yes, sounds good to me; thanks for the clarification. Applied. > > The hope is that there will be many applicants, and that we'll have > > the > > possibility to choose two. But if there is only one good > > candidate, I > > think we should not start another round of interviews until we > > evaluate > > the experience - because the process is expensive & time consuming. > > Sounds reasonable. > If it helps finding a consensus (minimize differences between the 2 > proposals at hand), I wonder whether it would make sense to rephrase > this, so that it becomes clear that having 2 would be preferred (and > just employing one if only one suitable candidate shows up is the > fallback), but for me personally, this explanation is enough and it > doesn't seem to make any difference in practice. OK, I've changed the default to 2, fallback to 1; and added a note for the Board to decide when no suitable
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, Am 09.06.22 um 13:03 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v St 08. 06. 2022 v 19:53 +0200: Interestingly I cannot remember TDF ever tendering for LibreOffice Online work, can you please point me to the details? TDF tendered in 2014/2015 the work for the Android editing, which was explained to the board also as important for LOOL. Thus this project was payed from the LibreOffice donation money. The biggest part of this work (according to the prize) was done by Collabora productivity. [But I may be wrong - as said, I have nothing to do with TDF tending process, so maybe I've missed something?] I made a research in an archive and found out that the document with the offer from Collabora was created by Jan Holesovsky with LibreOffice 4.2 on Oct., 6 2014. Sure, if we are talking the Android editing, then of course, I know what you are talking about. The work consisted of 478 commits, 265 of them were clearly marked as "android". The remaining 213 commits may still have been Android-only (and the author just forgot to mark them that way), or may have improved (the pre-existing, funded by CloudOn, Smoose and others) LibreOfficeKit with functionality needed for the Android work (I'd need to check commit by commit to tell you the exact number, so the 213 is the upper bound - it could be less). Anybody can check the reports, Collabora has published them previously: https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M1.pdf https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M2.pdf LibreOfficeKit was indeed important for what has started as LibreOffice Online thanks to the seed investment from IceWarp, but was just a part of what was necessary for the LibreOffice Online development. The completely missing bits, not existing previously & not paid by TDF, were the server and the JavaScript renderer of the tiles. To put the 213 commits to perspective, the server and JS bits were 12489 commits at the time of the Online repository move to GitHub. It is hard to count the commits done to LibreOfficeKit (ie. to LibreOffice this confirms that TDF has payed a part of the Android and Online development from donation money. core) before and after the TDF Android editing tender; but I suppose there were thousands, and they are still part of LibreOffice, of course. None of the server & JS commits were paid by TDF, it was all funded by IceWarp, Collabora itself & many others, and the price that TDF has paid for the 213 commits was marginal compared to the other work that made the Online happen. Please don't get me wrong though - I am really grateful for that, every cent counts, and especially counted the 8 years ago; for people at Collabora, those were hard (but exciting) times with very unpredictable future. And for the avoidance of doubt - all these 213 commits were needed for the Android work, none of them was done speculatively for a potentiald Online use later. If I remember correctly I attended a presentation from Michael M. about a LibreOffice online pre alpha version at the conference in Paris 2011. And thus I'm not able to reconstruct that in 2014/15 the LibreOffice online was speculatively. The tender in 2014/2015 was justified not only with foundation work for an Android version but also for an online version of LibreOffice. And it was flagged that would be a necessary investment for the future of LibreOffice (because mobile/online would be the future of office tools). Although Collabora took money from the charity TDF to develop LOOL, it forked this project and dry out the LOOL development under the TDF umbrella. That is a self-centered behavior and a damage of the foundation. Such a behavior is the opposite of a contribution to TDF/LibreOffice. 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] Merged proposal for in-house developers at TDF
Hi all, Am 09.06.22 um 08:53 schrieb Thorsten Behrens: Hi Andreas, all, Andreas Mantke wrote: Am 8. Juni 2022 22:35:01 MESZ schrieb Thorsten Behrens : As such, lets please get back to the topic. Because the acting people from that years hasn't realy changed I think that gives a clearer view on their mindset and agenda. It's important to help understanding the whole process in this thread. Hmm. I wonder how much of these discussions here really is about frustrations of the past (and people not liking each other), vs. interacting positively with new proposals. you may not understand that some people not share your idea of man. Although some board members are really hard trying to frustrate members/volunteers some participants work further for the good of the community and the foundation. And they follow their intrinsic motivation and work for their ideal. They don't want to see a prize tag on everything. And maybe such a view and behavior is scary for some involved. I think it would be in everyone's interest (in particular in TDF's interest), if we could discuss the merits of proposals and ideas independent of who brought them in. It would be very good if those with management functions would lead the discussion and wouldn't only stand at the sideline. It seemed there are different proposals on the table and the board needs to decide which direction to follow. The ESC btw is such a place, and therefore still quite a pleasant experience, with calm & constructive discussions between all stakeholders. You can discuss there, but you should abstain from double your impact by participating further in the board discussion / decision. And as a reminder: at least for free software companies has to be excluded from the tender process at least for the 2022 budget, because their staff / manager take responsibility for that whole budget (including the tender items). And further addition: the items in the 2022 budget are not fixed and couldn't changed or adjusted by a further board vote (thus there could and would be a budget for in-house developer available, if the board decided so). 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] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v St 08. 06. 2022 v 19:53 +0200: > > Interestingly I cannot remember TDF ever tendering for LibreOffice > > Online work, can you please point me to the details? > TDF tendered in 2014/2015 the work for the Android editing, which was > explained to the board also as important for LOOL. Thus this project > was > payed from the LibreOffice donation money. The biggest part of this > work > (according to the prize) was done by Collabora productivity. > > [But I may be wrong - as said, I have nothing to do with TDF > > tending > > process, so maybe I've missed something?] > > > I made a research in an archive and found out that the document with > the > offer from Collabora was created by Jan Holesovsky with LibreOffice > 4.2 > on Oct., 6 2014. Sure, if we are talking the Android editing, then of course, I know what you are talking about. The work consisted of 478 commits, 265 of them were clearly marked as "android". The remaining 213 commits may still have been Android-only (and the author just forgot to mark them that way), or may have improved (the pre-existing, funded by CloudOn, Smoose and others) LibreOfficeKit with functionality needed for the Android work (I'd need to check commit by commit to tell you the exact number, so the 213 is the upper bound - it could be less). Anybody can check the reports, Collabora has published them previously: https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M1.pdf https://www.collaboraoffice.com/wp-content/uploads/2020/09/TDF0002-report-M2.pdf LibreOfficeKit was indeed important for what has started as LibreOffice Online thanks to the seed investment from IceWarp, but was just a part of what was necessary for the LibreOffice Online development. The completely missing bits, not existing previously & not paid by TDF, were the server and the JavaScript renderer of the tiles. To put the 213 commits to perspective, the server and JS bits were 12489 commits at the time of the Online repository move to GitHub. It is hard to count the commits done to LibreOfficeKit (ie. to LibreOffice core) before and after the TDF Android editing tender; but I suppose there were thousands, and they are still part of LibreOffice, of course. None of the server & JS commits were paid by TDF, it was all funded by IceWarp, Collabora itself & many others, and the price that TDF has paid for the 213 commits was marginal compared to the other work that made the Online happen. Please don't get me wrong though - I am really grateful for that, every cent counts, and especially counted the 8 years ago; for people at Collabora, those were hard (but exciting) times with very unpredictable future. And for the avoidance of doubt - all these 213 commits were needed for the Android work, none of them was done speculatively for a potential Online use later. More details here: https://collaboraonline.github.io/post/faq/#mobile-story 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] Merged proposal for in-house developers at TDF
Hi Paolo, [last comment from me on this sub-thread] Paolo Vecchi wrote: > There isn't and hasn't been much debate going on and the ESC has > been asked to vote today about killing LOOL. > Whatever the outcome of the ESC discussion - moving to the attic is not 'killing' a project (which is an unnecessarily charged word anyway). Additionally, there has not been any commits to LOOL in almost 2 years. The status quo is already the 'attic', for anything but the name. And now let's wait for the ESC to act (or not). Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Thorsten, On 08/06/2022 22:35, Thorsten Behrens wrote: Dear list, Andreas Mantke wrote: Interestingly I cannot remember TDF ever tendering for LibreOffice Online work, can you please point me to the details? TDF tendered in 2014/2015 the work for the Android editing, which was explained to the board also as important for LOOL. That seems to be a very technical argument (on both sides); in any case I doubt that a discussion of something that happend 8 years ago helps us in moving the developer hiring proposal forward. Something that had a clear start, progression and support from TDF during the past 7 years shows the risks we may incur when different interests influence TDF and our community. As such, lets please get back to the topic. Paolo Vecchi wrote: With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda, during the meeting, the request to actually kill LOOL. From the emails on board-discuss it seems clear that that he doesn't want that in-house developers to even thinking about reviving LOOL to make sure TDF cannot promote even a basic version of it. Same here - mixing lots of other topics into this discussion is not useful in us making progress. Promoting an ineffective and expensive way to get some mentors and the proposal of killing LOOL are related as coming from a single person that might have conflicting interests and is not even a member of the ESC. It is also premature, since the ESC is still discussing the matter. There isn't and hasn't been much debate going on and the ESC has been asked to vote today about killing LOOL. Debating the merits of the proposal should happen there, not here (for the while). Unless the board wants to run its own, competing motion for how to deal with the Online repo (which I would consider nonconstructive). IMHO the ESC should deal with purely engineering issues, the intervention from a non ESC members shows that it has been abused as a "political" tool. What happened during the past 2 ESC meetings should be thoroughly investigated to see if undue influence from a conflicted party is an acceptable behaviour. Thanks, -- Thorsten Ciao Paolo -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- 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] Merged proposal for in-house developers at TDF
Hi Andreas, all, Andreas Mantke wrote: > Am 8. Juni 2022 22:35:01 MESZ schrieb Thorsten Behrens > : > >As such, lets please get back to the topic. > > > > Because the acting people from that years hasn't realy changed I > think that gives a clearer view on their mindset and agenda. It's > important to help understanding the whole process in this thread. > Hmm. I wonder how much of these discussions here really is about frustrations of the past (and people not liking each other), vs. interacting positively with new proposals. I think it would be in everyone's interest (in particular in TDF's interest), if we could discuss the merits of proposals and ideas independent of who brought them in. The ESC btw is such a place, and therefore still quite a pleasant experience, with calm & constructive discussions between all stakeholders. All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, Am 8. Juni 2022 22:35:01 MESZ schrieb Thorsten Behrens : >Dear list, > >Andreas Mantke wrote: >> > Interestingly I cannot remember TDF ever tendering for LibreOffice >> > Online work, can you please point me to the details? >> TDF tendered in 2014/2015 the work for the Android editing, which was >> explained to the board also as important for LOOL. >> >That seems to be a very technical argument (on both sides); in any >case I doubt that a discussion of something that happend 8 years ago >helps us in moving the developer hiring proposal forward. > >As such, lets please get back to the topic. > Because the acting people from that years hasn't realy changed I think that gives a clearer view on their mindset and agenda. It's important to help understanding the whole process in this thread. >Paolo Vecchi wrote: >> With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda, >> during the meeting, the request to actually kill LOOL. From the emails on >> board-discuss it seems clear that that he doesn't want that in-house >> developers to even thinking about reviving LOOL to make sure TDF cannot >> promote even a basic version of it. >> >Same here - mixing lots of other topics into this discussion is not >useful in us making progress. > >It is also premature, since the ESC is still discussing the >matter. Debating the merits of the proposal should happen there, not >here (for the while). Unless the board wants to run its own, competing >motion for how to deal with the Online repo (which I would consider >nonconstructive). > It is not constructive for the agenda of the acting members of the ESC. There are a lot active members with a CoI in the LOOL topic. Thus if they further act to force a decision in their direction and the board stops that not immediately it's according to the statutes time for the MC to step in (to prevent the foundation from further damage). Regards, Andreas -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. -- 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] Merged proposal for in-house developers at TDF
Dear list, Andreas Mantke wrote: > > Interestingly I cannot remember TDF ever tendering for LibreOffice > > Online work, can you please point me to the details? > TDF tendered in 2014/2015 the work for the Android editing, which was > explained to the board also as important for LOOL. > That seems to be a very technical argument (on both sides); in any case I doubt that a discussion of something that happend 8 years ago helps us in moving the developer hiring proposal forward. As such, lets please get back to the topic. Paolo Vecchi wrote: > With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda, > during the meeting, the request to actually kill LOOL. From the emails on > board-discuss it seems clear that that he doesn't want that in-house > developers to even thinking about reviving LOOL to make sure TDF cannot > promote even a basic version of it. > Same here - mixing lots of other topics into this discussion is not useful in us making progress. It is also premature, since the ESC is still discussing the matter. Debating the merits of the proposal should happen there, not here (for the while). Unless the board wants to run its own, competing motion for how to deal with the Online repo (which I would consider nonconstructive). Thanks, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, On 08/06/2022 19:53, Andreas Mantke wrote: Hi all, Am 06.06.22 um 13:18 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200: If I remember correctly TDF has paid a big part of work on the basics of LOOL. And maybe some former / current board member recognize which company was paid for that work from donation money. Interestingly I cannot remember TDF ever tendering for LibreOffice Online work, can you please point me to the details? TDF tendered in 2014/2015 the work for the Android editing, which was explained to the board also as important for LOOL. Thus this project was payed from the LibreOffice donation money. The biggest part of this work (according to the prize) was done by Collabora productivity. thanks for the reminder. Since then Collabora also benefited a lot from TDF's marketing, infrastructure and community support. That was all part of the discussion which has been ignored during the negotiation to get LOOL made available to the community but then they unilaterally decided to move to GitHub and not backport any fixes or features. With a very odd timing the 02/06/2022 Mr Meeks added to the ESC agenda, during the meeting, the request to actually kill LOOL. From the emails on board-discuss it seems clear that that he doesn't want that in-house developers to even thinking about reviving LOOL to make sure TDF cannot promote even a basic version of it. [But I may be wrong - as said, I have nothing to do with TDF tending process, so maybe I've missed something?] I made a research in an archive and found out that the document with the offer from Collabora was created by Jan Holesovsky with LibreOffice 4.2 on Oct., 6 2014. I guess anyone can forget to have created the documents that lead to the financing and support by TDF and the community of one of their major projects. Now that Kendy has been reminded from where LOOL came from he will probably vote differently the request to kill it in the ESC. Regards, Andreas Ciao Paolo -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- 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] Merged proposal for in-house developers at TDF
Hi all, Am 06.06.22 um 13:18 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200: If I remember correctly TDF has paid a big part of work on the basics of LOOL. And maybe some former / current board member recognize which company was paid for that work from donation money. Interestingly I cannot remember TDF ever tendering for LibreOffice Online work, can you please point me to the details? TDF tendered in 2014/2015 the work for the Android editing, which was explained to the board also as important for LOOL. Thus this project was payed from the LibreOffice donation money. The biggest part of this work (according to the prize) was done by Collabora productivity. [But I may be wrong - as said, I have nothing to do with TDF tending process, so maybe I've missed something?] I made a research in an archive and found out that the document with the offer from Collabora was created by Jan Holesovsky with LibreOffice 4.2 on Oct., 6 2014. 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] Merged proposal for in-house developers at TDF
Hi Kendy, all, On 31/05/2022 15.59, Jan Holesovsky wrote: Removal of section "App stores management": As mentioned earlier, I agree that it makes sense to separate the app store topic from the current proposal of hiring developers, and focus on areas that are currently not receiving enough attention otherwise. Please don't get me wrong - I believe the appstores is an important discussion, just don't want to block the hiring on that; as I think it is orthogonal to that. I used to agree here. In light of the recent BoD decision that TDF will publish LO in the app stores [1] however, I think it is fair to reconsider this, and consider development needed to keep LO in line with app store requirements as a potential target area for TDF-internal developers, unless that's already covered otherwise. (By now, the underlying decision to publish in the app store has already been taken separately. Unless ecosystem members still plan to keep LO up to date with app store requirements for publishing their own LO derivatives, or this is already covered by the team, it seems that this might become an "unmaintained" area. But of course, I am lacking the background of the decision and what was discussed there.) In that regard, the "App stores management" section in Paolo's updated proposal (v2.1) looks reasonable to me at first sight. The following passage in that section is a bit unclear to me: It is also expected that while the Targeted Developer is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas. Can you clarify what that means in practice? Ah - it is the extension of the rationale how the development itself fits the TDF mission, ie. doesn't make that much sense without the previous paragraph that starts "Why is it important to major on mentoring". So how about: "Development per se is not part of TDF mission, but it is expected that while a mentor is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas." Does it make more sense this way? I'm not sure. It's still a bit unclear to me what "researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas" means in practice, s.a. questions in my previous emails. I have the impression that my personal understanding/perspective of the job of a targeted developer is a bit different from the one outlined in your proposal, and more in line with Paolo's when there are no mentees in the developer's target areas. That would seem reasonable to me: * If there are mentees in the target area, mentoring is the primary focus (as outlined in your proposal). * However, if there are no mentees, it's the primary focus to do development in the target area. Quoting from my previous email: (I think it definitely makes sense to get deeper into the topic and cooperate with other organizations and free software projects. I still think that the main focus should be to achieve practical improvements in LO. Depending on the target area, I can think of more or less way that this would naturally involve contributing to other free software projects etc, but - given limited resource - I personally wouldn't necessarily see contributing to other projects or doing research as a main goal by itself, at least not in the beginning.) After all, it seems to be a matter of setting priorities how TDF money is spent, and one can decide one way or the other. I can't judge how well each option fits with the "Development per se is not part of TDF mission" you mention, but to me, doing "development per se" doesn't seem to be less in line with the TDF mission than spending money on tenders, as was mentioned elsewhere in one of the threads already. Indeed, I should clarify this; I think changing "Overlaps or prioritisations that find ..." to "Technical decisions that find..." could do? Yes, sounds good to me; thanks for the clarification. Section "Bootstrapping": The initial proposal suggests to employ 2 developers, while the modified one suggests to "start with hiring a single Targeted Developer initially, with the option to expand this to two if multiple suitable candidates present at the interview stage". What's the practical difference of the initial proposal of planning to hire two developers (and then only employing one, if only one suitable candidate shows up) and the new proposal? Does this mostly mean that there will be no further job advertisement once a first developer has been employed, or is there more to it?
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Ne 05. 06. 2022 v 19:12 +0200: > If I remember correctly TDF has paid a big part of work on the basics > of > LOOL. And maybe some former / current board member recognize which > company was paid for that work from donation money. Interestingly I cannot remember TDF ever tendering for LibreOffice Online work, can you please point me to the details? [But I may be wrong - as said, I have nothing to do with TDF tending process, so maybe I've missed something?] 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] Merged proposal for in-house developers at TDF
Hi Cor, all, Am 02.06.22 um 23:17 schrieb Cor Nouws: Hi Andreas, Thanks for your answer, Andreas Mantke wrote on 01/06/2022 20:13: Am 01.06.22 um 11:48 schrieb Cor Nouws: Andreas Mantke wrote on 31/05/2022 19:49: I only could see the difference that in one case TDF has full control I do not understand what you mean. What is full control over open source code? it means control not over the source code per se, but over the direction of the development from a TDF point of view and the modules etc. TDF think are useful or needed by the community (and the user of the program and the donor). TDF now chooses the projects for the tenders, so already does have that influence. a) TDF could choose projects for tenders, but is dependent of commercial free software companies that want to work on that project and in TDF's direction. If there is no will or ability to work on a project there will be no development. b) TDF has very low impact on the price of the development (because the market is oligopoly/monopoly). c) currently there is an impact potentialization of commercial free software companies from a combination of ESC and board membership. They have a determining impact in both bodies and that is not really healthy for a foundation, including and relying not only on developers (but also community members, which help end users, write documentation, did marketing etc.). And this means TDF need to decide and operate independent from any commercial company. I think it is fair to include also the organizations that use LibreOffice (and make use of services of commercial organizations for support/improving) as part of our wide community. They could participate in person in the same way as every community member did. But currently they have no right to stop a development, that TDF and its community think is important. And in addition: the commercial companies are not the most important ones in the community. They are part of it, but there were/are a lot of people that were/are doing a lot of work (sometimes very tedious), without TDF/LibreOffice wouldn't be successful. I got the impression that it would be a step forward, if some developer and software companies would value highly the work of the non-developer for the project. It's important to recognize, that LibreOffice is an end user product and not something running on a server, managed by an admin. And also: TDF is founded thanks to (also, among others) the massive help of our commercial ecosystem. TDF with in-house developer could avoid a situation like the one with LOOL (I'm not sure that this opinion is common ground inside the current board). I'm not sure. LOOL started thanks to tedious hard work with great risk, pushed by the need to make it an success in the market. For me (having seen commercial and idealistic activities in many areas) it's hard to imagine that a voluntary driven foundation can have the same understanding of and interaction with a business market. But we're diverging a bit too much, if we redo all the previous discussions on that matter here, I think. (covering some highlights at a beer, looks better to me ;) ) If I remember correctly TDF has paid a big part of work on the basics of LOOL. And maybe some former / current board member recognize which company was paid for that work from donation money. and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. It is indeed an interesting question to look at effectiveness of TDF-spendings. In case it is clear that in house development would result better work for the foundations goals, that is something we cannot easily ignore. (I would not be able to set some data there ;) ) But of course other aspects to consider there are: how can TDF be growing the ecosystem, which I think is one of the most important challenges of the LibreOffice project, and not compete with the ecosystem. (Different subject, that as far as I am concerned will be at the table to work on soon.) I stated already in another email that tendering produces a lot of overhead and consumes a lot of TDF/community resources (and also extra I think you underestimate the costs/overhead of having in house developers. And for their work too, it is necessary to plan the activity, evaluate milestones and check the results of in-house developers. I think you also underestimate the advantages commercially driven organizations have. (Mind that I'm not at all suggesting that commercial organizations are the best choice for everything ;) ). But TDF has to do the same for its current staff. Thus it should have some experience in this field. But please read the mail from László: explanation by real life examples. This shows only that life is not always easy. But I think he and others were able to get enough experience and to work on the LibreOffice code with passion
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Ilmari, Ilmari Lauhakangas wrote: > On 3.6.2022 11.58, Thorsten Behrens wrote: > > [1] curious as in - how much weight should that carry, when writing > > the job posting / assessing skills? > > It's a necessity. I have newbie level experience that I definitely hope to > grow alongside all the other interesting tasks. > Perhaps I misunderstood the need then - I took it as having general technical expertise, such as reading code, assessing tests and deliverables. Those in my experience are relatively generic skills, and translate well across different areas of the project. So that's not what you had in mind, but rather deep expertise, to the level of 'I could have written the code myself'? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Cor, On 03/06/2022 13:16, Cor Nouws wrote: Hi Paolo, Paolo Vecchi wrote on 03/06/2022 11:53: ... Another reason why I did not want to share my proposal open for editing to anyone is that it might happen that someone writes something that should not be written in a public document. We want a public discussion (of course not when it does not fit) but prevent people to write in a document because they may write something odd... after all there is this mailing list where * can write * ¯\_(ツ)_/¯ :D When you send an email you are responsible for what you write and TDF might become responsible to take down the content from the archives if the content is offensive/illegal. If you write something in my proposal then I'm also responsible for checking that you are not adding something that could be problematic. .. We will publish public tenders open to all ensuring that there will be a level playing field so that any organisation will be able to participate. You may have missed something, but that is standing policy. We know that but it could be that Simon, with his comment, forgot about it. Cheers, Ciao Paolo -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Čt 02. 06. 2022 v 18:34 +0200: > But seriously: you behave in a way which is unworthy for a leader of > an > OSS project. The TDF community consists not only from TDF members. > And > you denigrate all participants which are not TDF member. This damages > the whole LibreOffice/TDF community. I'm afraid this is a misunderstanding. I meant to point out that TDF has the members, the Board and elections for a reason, particularly when we are talking strategic projects affecting the TDF future. But after re-reading, I appreciate the paragraph might have sounded arrogantly. If it offended you, please accept my apology. 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] Merged proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi wrote on 03/06/2022 11:53: ... Another reason why I did not want to share my proposal open for editing to anyone is that it might happen that someone writes something that should not be written in a public document. We want a public discussion (of course not when it does not fit) but prevent people to write in a document because they may write something odd... after all there is this mailing list where * can write * ¯\_(ツ)_/¯ :D .. We will publish public tenders open to all ensuring that there will be a level playing field so that any organisation will be able to participate. You may have missed something, but that is standing policy. Cheers, -- 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] Merged proposal for in-house developers at TDF
On 3.6.2022 11.58, Thorsten Behrens wrote: Ilmari Lauhakangas wrote: Tendering and in-house development are not interchangeable, but they are interlinked. Keep in mind that the in-house devs would participate in running tenders. That's a possibility, yeah. But just curious [1], is that currently a bottleneck for tenders? Since there's you, Cloph, Hossein and Xisco already, with cumulative many years of development experience. [1] curious as in - how much weight should that carry, when writing the job posting / assessing skills? It's a necessity. I have newbie level experience that I definitely hope to grow alongside all the other interesting tasks. Now I should look in the mirror, give myself a motivational slap in the face and quote László: "How many months are we talking about? 3, 6 months, or a few dozen, i.e. a few years? Or never?" Ilmari -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Simon, On 03/06/2022 10:59, Simon Phipps wrote: Hi! On Fri, Jun 3, 2022 at 7:51 AM Ilmari Lauhakangas wrote: Tendering and in-house development are not interchangeable, but they are interlinked. Keep in mind that the in-house devs would participate in running tenders. Another valuable role for an in-house developer would be to manage a more long-term relationship with specialist subcontractors, for example a company with expertise in accessibility development. With a longer-term expert subcontractor, TDF could then actually develop new capabilities rather than simply fix bugs and stand still like AOO. By adding to our list of approaches a managed but non-employee longer-term relationship with outside firms that is not limited to a single task, TDF would be able to both benefit from the flexibility of tendering and also gain the benefit of long-term staffing. You may have missed that my proposal already mentions something about it in page 9: "Their general role will be to fix bugs and features in full, fixing bugs that are blockers for community contributors and to help evaluating which complex tasks should be tackled by external specialists." https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB It was an excellent idea to make the document editable, thanks Kendy, so I have added some words to this effect. Feel free to improve them! Another reason why I did not want to share my proposal open for editing to anyone is that it might happen that someone writes something that should not be written in a public document. Stating the name of a supplier and the way we would want to engage with them could reduce our bargaining power to get the best deal for TDF. We will publish public tenders open to all ensuring that there will be a level playing field so that any organisation will be able to participate. Cheers Simon -- *Simon Phipps* /TDF Trustee/ Ciao Paolo -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details:https://www.documentfoundation.org/imprint OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi! On Fri, Jun 3, 2022 at 7:51 AM Ilmari Lauhakangas < ilmari.lauhakan...@libreoffice.org> wrote: > > Tendering and in-house development are not interchangeable, but they are > interlinked. Keep in mind that the in-house devs would participate in > running tenders. > Another valuable role for an in-house developer would be to manage a more long-term relationship with specialist subcontractors, for example a company with expertise in accessibility development. With a longer-term expert subcontractor, TDF could then actually develop new capabilities rather than simply fix bugs and stand still like AOO. By adding to our list of approaches a managed but non-employee longer-term relationship with outside firms that is not limited to a single task, TDF would be able to both benefit from the flexibility of tendering and also gain the benefit of long-term staffing. It was an excellent idea to make the document editable, thanks Kendy, so I have added some words to this effect. Feel free to improve them! Cheers Simon -- *Simon Phipps* *TDF Trustee*
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Ilmari, all, Ilmari Lauhakangas wrote: > Tendering and in-house development are not interchangeable, but they are > interlinked. Keep in mind that the in-house devs would participate in > running tenders. > That's a possibility, yeah. But just curious [1], is that currently a bottleneck for tenders? Since there's you, Cloph, Hossein and Xisco already, with cumulative many years of development experience. [1] curious as in - how much weight should that carry, when writing the job posting / assessing skills? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
On 2.6.2022 21.50, laszlo.nem...@documentfoundation.org wrote: Also tendering and in-house development are not interchangeable. The planned in-house development with 1-2 developers is not a viable option for LibreOffice development without the development activity of a couple dozen developers of these 4-5 companies (Collabora Productivity, allotropia, Red Hat Linux, NISZ, etc.) and unaffiliated developers (https://www.documentfoundation.org/gethelp/developers/). Likely the planned in-house development could spare a few tenders per year for the same or double price. If we are extremely lucky, we could spare much more, but if one of the companies, e.g. my client terminates LibreOffice development (because its long-term "aim to leave the development for the community"), the price could be much higher for the LibreOffice community, because the 1-2 new in-house developers couldn't replace losing 5 or more developers. Check my previous numbers about the real risk: how my client tries to find and keep the good developers continuously. Tendering and in-house development are not interchangeable, but they are interlinked. Keep in mind that the in-house devs would participate in running tenders. Ilmari -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
hello Paolo, On 02.06.22 19:55, Paolo Vecchi wrote: > > Also thanks to Andreas comment about the ESC minutes I had a look at > last week and today's minutes and it seems like Michael Meeks is already > implementing his proposal, transposed mostly by copy/paste by Kendy in > his own proposal (which BTW hasn't been renamed yet), with some > unexplained urgency and without anyone informing the board. if memory serves (and i'm sorry to say i missed last week's meeting due to a public holiday), the ESC discussed this topic because there was an urgency expressed on this list [1] regarding the hiring of in-house developers/mentors by TDF. one of the questions with this plan is which problem domains the in-house developers would be working on, that is, which are the areas that are actively used but under-maintained currently, so that for example expertise in such areas could be considered when evaluating applicants. hence the question was brought to the ESC to draw on the experience of its members in diverse areas of the code base, and the ESC attempted to come up with a list of such under-maintained areas in a collective effort, in order to expedite the TDF hiring process. the current version of the list, imperfect and unfinished as it is, is public in the TDF Wiki. also there was a follow-up discussion on the public mailing list, with about half a dozen people with various backgrounds - including several community members who are not in the ESC - provided additional input that can been taken into account. in case the board no longer considers hiring to be urgent, or is not interested in advice prepared by the ESC and sourced from the developer community, i think the ESC (who i don't speak for, this is just my personal opinion) would be most happy to stop discussing this topic and come back to it at a later date; please advise us of your preference in this regard. best regards, michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00540.html -- 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] Merged proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi wrote on 02/06/2022 22:59: thanks for your extensive explanation which I really appreciate as I appreciate your contributions both during your working hours and as a volunteer. We surely are all working with passion to reach the same goal and we have specialisations that allow us to view things from different but complementary perspectives. I know it is difficult to follow long threads where I provided further You need help? :) clarifications about my proposal but what you are saying has already been taken in consideration. IMO only partly. It is useful explanation to set realistic expectations. Young and passionate developers with the will to learn and adapt will not replace the tenders, they will start with focusing on areas that haven't been covered by others as much as we wished. It is indeed an important outcome of the discussion that there are ways to complement, and not to compete with the commercial ecosystem. Finding senior C++ or experienced LibreOffice developers willing to mentor is very difficult and/or very expensive as they already have a good and very well paid position so even if they have a huge passion for LibreOffice and our community is unlikely we'll be able to match what some large corporations can offer. As from my proposal: "The developers will not need to have a narrow specialisation in the proposed areas but a good understanding of them, willingness to learn and to adapt will be necessary characteristics of the candidates. Their general role will be to fix bugs and features in full, fixing bugs that are blockers for community contributors and to help evaluating which complex tasks should be tackled by external specialists." Thanks to the mentors that we already have in our team, if they have the passion and the right attitude, they will grow to become excellent developers and if they wish even join the ranks of mentors in the long I love your optimism (well, not always), but as you can read in Lászlo's mail: there's huge uncertainty. run. Not all developers want to become mentors or do presentation in public, some just prefer to focus on the development side and we should enable our team to express their best skills the way they are most comfortable with. That is true. However more mentoring power is needed to. So if we can combine the two, it's better I would say. There are surely risks in doing that but I believe there are even bigger risks in not doing it. The biggest risk that we have in doing it is that we invest in forming developers that then might go back on the market You are thinking about a contract that forbids people to switch? ;) and anyway contribute. That's one of our goals anyway. If we get it right we'll have developers that start working on things that other volunteers may want to take on again as they see that things are moving in the right direction. Let me not take that too negative, but I assume developers are driven by the wish to make cool stuff. And there are enough opportunities for that in the source/product. What is clear is that the process I started with my proposal allowed to bring to light areas that did not receive enough attention and now commercial contributors, volunteers and in-house developers will start working together to fix those areas. IMO there is clearly room for that. See my mail from 23:17 CET I'm sure there will be a lot of fun to be had for everyone ;-) Could well be - let's hope it works out fine. 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] Merged proposal for in-house developers at TDF
Hi Andreas, Thanks for your answer, Andreas Mantke wrote on 01/06/2022 20:13: Am 01.06.22 um 11:48 schrieb Cor Nouws: Andreas Mantke wrote on 31/05/2022 19:49: I only could see the difference that in one case TDF has full control I do not understand what you mean. What is full control over open source code? it means control not over the source code per se, but over the direction of the development from a TDF point of view and the modules etc. TDF think are useful or needed by the community (and the user of the program and the donor). TDF now chooses the projects for the tenders, so already does have that influence. And this means TDF need to decide and operate independent from any commercial company. I think it is fair to include also the organizations that use LibreOffice (and make use of services of commercial organizations for support/improving) as part of our wide community. And also: TDF is founded thanks to (also, among others) the massive help of our commercial ecosystem. TDF with in-house developer could avoid a situation like the one with LOOL (I'm not sure that this opinion is common ground inside the current board). I'm not sure. LOOL started thanks to tedious hard work with great risk, pushed by the need to make it an success in the market. For me (having seen commercial and idealistic activities in many areas) it's hard to imagine that a voluntary driven foundation can have the same understanding of and interaction with a business market. But we're diverging a bit too much, if we redo all the previous discussions on that matter here, I think. (covering some highlights at a beer, looks better to me ;) ) and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. It is indeed an interesting question to look at effectiveness of TDF-spendings. In case it is clear that in house development would result better work for the foundations goals, that is something we cannot easily ignore. (I would not be able to set some data there ;) ) But of course other aspects to consider there are: how can TDF be growing the ecosystem, which I think is one of the most important challenges of the LibreOffice project, and not compete with the ecosystem. (Different subject, that as far as I am concerned will be at the table to work on soon.) I stated already in another email that tendering produces a lot of overhead and consumes a lot of TDF/community resources (and also extra I think you underestimate the costs/overhead of having in house developers. And for their work too, it is necessary to plan the activity, evaluate milestones and check the results of in-house developers. I think you also underestimate the advantages commercially driven organizations have. (Mind that I'm not at all suggesting that commercial organizations are the best choice for everything ;) ). But please read the mail from László: explanation by real life examples. This is all not to say that there is no room for in house development (as I repeatedly stated). During this discussion (and in fact quite early) various areas are noted that are (for obviously market reasons, I would say) badly covered by commercial ecosystem. So focus on that, definitely helps, without competing with our commercial ecosystem. But then still: learning managing in house development, cannot be underestimated. Also many will try to get their most important features, pet-bugs fixed etc.. Needs to be handled in a acceptable way too... money). Tendering also preclude TDF (and its staff / developers etc.) from gaining more knowledge about working on the source code etc. That does not have to be the case. Anyone is free to study the source etc. And help is all around. So the positive and interesting aspect in this subject is to find the areas where that is the case. And it's clear that those have been defined. And combining development and mentoring is also good for growing at least the developer base. Then the only discussion is: what is a sensible way to effectively manage in house developers/mentors. And, brushing in my opinion here: the combined knowledge of code, development, and existing needs, is best found in our ESC, with its broad composition, open meetings etc. It should be very clear that only TDF (board, ED) are managing the in-house developer. They are HR manager and the functional manager (maybe including some senior staff member). The ESC has no mandate to I respect your opinion, but I do not agree with it. The ESC is the place where deep knowledge of the product and development is combined. No better place to manage development, I would say. And in case there is a lot to choose from that is evenly easy/good to develop, I think board and ESC are well capable to come up with a mechanism to get input from the wider community. (Anyway, that would be my
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Laszlo, thanks for your extensive explanation which I really appreciate as I appreciate your contributions both during your working hours and as a volunteer. We surely are all working with passion to reach the same goal and we have specialisations that allow us to view things from different but complementary perspectives. I know it is difficult to follow long threads where I provided further clarifications about my proposal but what you are saying has already been taken in consideration. Young and passionate developers with the will to learn and adapt will not replace the tenders, they will start with focusing on areas that haven't been covered by others as much as we wished. Finding senior C++ or experienced LibreOffice developers willing to mentor is very difficult and/or very expensive as they already have a good and very well paid position so even if they have a huge passion for LibreOffice and our community is unlikely we'll be able to match what some large corporations can offer. As from my proposal: "The developers will not need to have a narrow specialisation in the proposed areas but a good understanding of them, willingness to learn and to adapt will be necessary characteristics of the candidates. Their general role will be to fix bugs and features in full, fixing bugs that are blockers for community contributors and to help evaluating which complex tasks should be tackled by external specialists." Thanks to the mentors that we already have in our team, if they have the passion and the right attitude, they will grow to become excellent developers and if they wish even join the ranks of mentors in the long run. Not all developers want to become mentors or do presentation in public, some just prefer to focus on the development side and we should enable our team to express their best skills the way they are most comfortable with. There are surely risks in doing that but I believe there are even bigger risks in not doing it. The biggest risk that we have in doing it is that we invest in forming developers that then might go back on the market and anyway contribute. That's one of our goals anyway. If we get it right we'll have developers that start working on things that other volunteers may want to take on again as they see that things are moving in the right direction. What is clear is that the process I started with my proposal allowed to bring to light areas that did not receive enough attention and now commercial contributors, volunteers and in-house developers will start working together to fix those areas. I'm sure there will be a lot of fun to be had for everyone ;-) Ciao Paolo On 02/06/2022 20:50, laszlo.nem...@documentfoundation.org wrote: Hi, Sorry, I hope my late answer will be as friendly and productive as I intended it to be. On 2022-06-01 17:23, Andreas Mantke wrote: Hi all, Am 01.06.22 um 11:11 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Út 31. 05. 2022 v 19:49 +0200: I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in- house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. Also when TDF switches targets, it has to pay for the time the developers have to spend learning the new area. On the other hand, the tendering is (and always has been) only budgeted from the excess, as the last thing after all the other costs (staff, marketing, infrastructure, etc. etc.) are covered - which gives TDF much more freedom in the planning: it can decide not to tender at all, if all the other costs give no room for that (and avoid hard decisions where to cut - infrastructure? conference? or even jobs?). I'm not sure if you're really thinking such simply or if you try to throw smoke grenades further. It seemed you try to create the impression that a contract of an in-house-developer is always for livelong and thus a big mandatory expense for a very long time. But I think you as the general manager of a commercial company should know better (?). The management of in-house developer is more lean and direct. Instead if you tender the development tasks you have to publish and advertise the tender, evaluate the bids, evaluate the milestones and the result(s). This is whole process consumes a lot of work time from TDF staff, board members and/or volunteers, which will be lacking in other important areas of the TDF/LibreOffice project then. Because a commercial company has to calculate in unforeseeable
Re: Details about CoI - Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, Am 02.06.22 um 16:14 schrieb Emiliano Vavassori: Hi all, I think it is just fair to add some small details about the how a CoI should be processed as food for thoughts and only for the sake of the argument. Il 02/06/22 12:32, Jan Holesovsky ha scritto: Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. Removing a CoI does *not* need to result in a stepping down of a director, nor there is the provision to do so. The Rules of Procedures for the Board of Directors [1] and specifically the 1.3.2 version of the CoI Policy that was amended just this year and that is linked at that page are some nice starting points. in some cases it could be solved with some smaller steps, But the board in total (and every directory in person) take the responsibility for the whole budget and every budget item. And if there is a CoI regarding the budget, the appropriate measure would be the step down. There is no possibility of 'cherry picking' regarding budget items for any of the directors. 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] Merged proposal for in-house developers at TDF
Hi, Sorry, I hope my late answer will be as friendly and productive as I intended it to be. On 2022-06-01 17:23, Andreas Mantke wrote: Hi all, Am 01.06.22 um 11:11 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Út 31. 05. 2022 v 19:49 +0200: I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in- house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. Also when TDF switches targets, it has to pay for the time the developers have to spend learning the new area. On the other hand, the tendering is (and always has been) only budgeted from the excess, as the last thing after all the other costs (staff, marketing, infrastructure, etc. etc.) are covered - which gives TDF much more freedom in the planning: it can decide not to tender at all, if all the other costs give no room for that (and avoid hard decisions where to cut - infrastructure? conference? or even jobs?). I'm not sure if you're really thinking such simply or if you try to throw smoke grenades further. It seemed you try to create the impression that a contract of an in-house-developer is always for livelong and thus a big mandatory expense for a very long time. But I think you as the general manager of a commercial company should know better (?). The management of in-house developer is more lean and direct. Instead if you tender the development tasks you have to publish and advertise the tender, evaluate the bids, evaluate the milestones and the result(s). This is whole process consumes a lot of work time from TDF staff, board members and/or volunteers, which will be lacking in other important areas of the TDF/LibreOffice project then. Because a commercial company has to calculate in unforeseeable problems and realize a profit, the price for a tender is much higher. In addition the number of commercial companies, able to work on such LibreOffice source code tenders, is - spoken guarded - very clearly laid out. If we would see such 'diversity' outside of the TDF world we would name it a monopoly/oligopoly market and wouldn't expect a real competion. Over all I think the above answer shows that the role of a general manager of a commercial company, which has some interest in TDF tendering development, has a huge CoI with the TDF role(s). Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Jan 'Kendy' Holešovský is not a "general manager" of "a commercial company", but engineering manager of Collabora Productivity, and founder and board member of TDF (https://www.documentfoundation.org/governance/history/, https://www.documentfoundation.org/governance/board/), one of the most productive developers of LibreOffice (2673 core commits, and 1000+ in Online), volunteering in the board, ESC, in the certification committee and on LibO hackfests, and last but not least, one of my kindest ex-colleagues. He tried to explain the risk of in-house development compared to tendering, answering your question. Tendering *guarantees* the result for the money, in-house development doesn't, proofed by my experience, too. The risk is not only losing money, but losing opportunity to fix as many bugs as possible, and losing trust in TDF, reducing volunteering in development (also from volunteering employees and owners of free software developer companies). I know this risk. I'm a contractor of a 2000-employee company. I develop LibreOffice and mentor (recently) 4 LibreOffice programmers, but mentoring previously a *dozen* other ones, who mostly failed in LibreOffice development. See my presentations about in-house LibreOffice development and mentoring: http://libreoffice.hu/build-your-libreoffice-development-team/ http://numbertext.org/libreoffice/nemeth_libocon2019.pdf If you check (the end of the) presentations, it's all about risk-minimization. Hiring has got its difficulties. For example, TDF wants a LibreOffice developer, but one of the applicants, the only certified LibreOffice developer with 15+ years experience is not sympathetic or she asks for too much, so TDF decides to hire someone with professional C++ experience, but without LibreOffice development experience. Why not? You may think naively, that within a few months you can get an experienced LibreOffice developer or development mentor, because LibreOffice is a C++ project. Time doesn't matter, because after having a professional LibreOffice developer, TDF will be able
Re: Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
Hi Thorsten, On 02/06/2022 19:02, Thorsten Behrens wrote: Dear list, Kendy & Andreas, let me repeat my earlier request to keep the interaction on this list friendly and productive. In particular, don't offend, and try not to be offended. This part of the thread is not making progress towards coming up with a final, merged proposal for in-house developers. thanks for defusing a conversation that was going in the wrong direction but I think that Andreas has brought to the discussion quite a few very good points. It's rather unfortunate that Kendy did not reply in a constructive manner to several of Andreas, IMHO, valid objections to his proposal, some of which go along the lines of what I was about to reply. Also thanks to Andreas comment about the ESC minutes I had a look at last week and today's minutes and it seems like Michael Meeks is already implementing his proposal, transposed mostly by copy/paste by Kendy in his own proposal (which BTW hasn't been renamed yet), with some unexplained urgency and without anyone informing the board. That just reinforced my belief, shared apparently also by Andreas, that a body in which third party companies seem to be able to impose their will should not direct TDF's employees in any way at all. I've asked the board to evaluate the situation to see if further actions should be taken. Thanks a lot, -- Thorsten Ciao Paolo -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint OpenPGP_signature Description: OpenPGP digital signature
Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
Dear list, Kendy & Andreas, let me repeat my earlier request to keep the interaction on this list friendly and productive. In particular, don't offend, and try not to be offended. This part of the thread is not making progress towards coming up with a final, merged proposal for in-house developers. Thanks a lot, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi, Am 02.06.22 um 12:32 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200: Am 01.06.22 um 11:11 schrieb Jan Holesovsky: The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. It seemed you try to create the impression that a contract of an in-house-developer is always for livelong and thus a big mandatory expense for a very long time. If you have a look at the history of TDF staff, you will see that only very few people have ever left it. I am very pleased that we have people working for TDF even for around 10 years, and most of the people stay for lng periods - which is great for continuity of course. hey, you showed that you have either no knowledge about staff contract regulations or you try to throw smoke grenades and trick the community again. But I think you as the general manager of a commercial company should know better (?). Unfortunately you are very confused about my role in Collabora it seems. My role is "People Development Manager" - which is a nice sounding title for a mentor. I have no company shares, and no executive role there. The Collabora website shows that you are one of the managers of this commercial company: https://www.collaboraoffice.com/about-us/ And thus it is very obvious that you have no interest in the amount of TDF tenders (for working on LibreOffice source code). You should not try to take the community and the public for a fool. Such behavior disqualified for a role in the board of TDF. Because a commercial company has to calculate in unforeseeable problems and realize a profit, the price for a tender is much higher. On the other hand, the commercial company has to assume there are other competing companies in the process, so every bid is (and has to be) risky and as cheap as possible. Please stop kidding: I currently know only two commercial companies that are able to bid on LibreOffice source code tender. Thus there is no competing market yet. It's more of a monopoly / oligopoly market. And nearly everyone knows about the formation of prices in such market from her / his daily experience. I am not directly involved, but I have heard that Collabora were actually losing money on some tenders, so TDF got a much better deal than it would do with internal developers. And it is not Collabora's fault, it is one of the reasons why "tendering" exists as a tool in general. If that loosing money on tenders would be true, it is clear that you have a CoI with your roles at Collabora and at TDF. Over all I think the above answer shows that the role of a general manager of a commercial company, which has some interest in TDF tendering development, has a huge CoI with the TDF role(s). I am not a general manager, I have no personal interest in the tenders and I have no shares from the tenders. See above. I have no CoI in the process of drafting the proposal. I have large experience in development and in mentoring, so I have the experience and skills needed for drafting the proposal. And maybe Collabora is also very happy that you have such experience and you are involved in writing proposals for them too? Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. A apologize for lèse majesty. You stated correctly that I'm a nobody (not seriously speaking). But seriously: you behave in a way which is unworthy for a leader of an OSS project. The TDF community consists not only from TDF members. And you denigrate all participants which are not TDF member. This damages the whole LibreOffice/TDF community. You should draw the appropriate measures now and avert further damage from TDF/LibreOffice (community). 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
Details about CoI - Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi all, I think it is just fair to add some small details about the how a CoI should be processed as food for thoughts and only for the sake of the argument. Il 02/06/22 12:32, Jan Holesovsky ha scritto: Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. Removing a CoI does *not* need to result in a stepping down of a director, nor there is the provision to do so. The Rules of Procedures for the Board of Directors [1] and specifically the 1.3.2 version of the CoI Policy that was amended just this year and that is linked at that page are some nice starting points. Andreas also addressed the whole Board, not directly Jan Holesovsky. As per §8.4 of the Statutes, "The Board of Directors prevents possible conflicts of interest within the foundation." and that statement is binding to the public (since it is in our Statutes), not only if complaints come from members of the Foundation or the community. I'm explicitly being silent on the main topic of the thread or the alleged CoI (for the latter, it is responsibility of the Board, not Jan's nor Emiliano's, to determine if it exists). Cheers, [1]: https://wiki.documentfoundation.org/TDF/BoD_rules -- Emiliano Vavassori syntaxerror...@libreoffice.org OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v St 01. 06. 2022 v 17:23 +0200: > Am 01.06.22 um 11:11 schrieb Jan Holesovsky: > > > > The difference is that once you hire a developer / developers, the > > development becomes a mandatory expense - TDF has to pay their wage > > every month. > > It seemed you try to create the impression that a contract of an > in-house-developer is always for livelong and thus a big mandatory > expense for a very long time. If you have a look at the history of TDF staff, you will see that only very few people have ever left it. I am very pleased that we have people working for TDF even for around 10 years, and most of the people stay for lng periods - which is great for continuity of course. > But I think you as the general manager of > a commercial company should know better (?). Unfortunately you are very confused about my role in Collabora it seems. My role is "People Development Manager" - which is a nice sounding title for a mentor. I have no company shares, and no executive role there. > Because a > commercial company has to calculate in unforeseeable problems and > realize a profit, the price for a tender is much higher. On the other hand, the commercial company has to assume there are other competing companies in the process, so every bid is (and has to be) risky and as cheap as possible. I am not directly involved, but I have heard that Collabora were actually losing money on some tenders, so TDF got a much better deal than it would do with internal developers. And it is not Collabora's fault, it is one of the reasons why "tendering" exists as a tool in general. > Over all I think the above answer shows that the role of a general > manager of a commercial company, which has some interest in TDF > tendering development, has a huge CoI with the TDF role(s). I am not a general manager, I have no personal interest in the tenders and I have no shares from the tenders. I have no CoI in the process of drafting the proposal. I have large experience in development and in mentoring, so I have the experience and skills needed for drafting the proposal. > Thus I'd > expect that this CoI should be solved asap and the appropriate > measures > taken to prevent TDF from further damage. Are you, a TDF non-member, actually asking me, an _elected_ Board Member, to step down? That is a very ridiculous demand. 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] Merged proposal for in-house developers at TDF
+1 Paolo On 01/06/2022 20:13, Andreas Mantke wrote: Hi Cor, all, Am 01.06.22 um 11:48 schrieb Cor Nouws: Hi Andreas, Andreas Mantke wrote on 31/05/2022 19:49: I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in-house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control I do not understand what you mean. What is full control over open source code? it means control not over the source code per se, but over the direction of the development from a TDF point of view and the modules etc. TDF think are useful or needed by the community (and the user of the program and the donor). And this means TDF need to decide and operate independent from any commercial company. TDF with in-house developer could avoid a situation like the one with LOOL (I'm not sure that this opinion is common ground inside the current board). and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. It is indeed an interesting question to look at effectiveness of TDF-spendings. In case it is clear that in house development would result better work for the foundations goals, that is something we cannot easily ignore. (I would not be able to set some data there ;) ) But of course other aspects to consider there are: how can TDF be growing the ecosystem, which I think is one of the most important challenges of the LibreOffice project, and not compete with the ecosystem. (Different subject, that as far as I am concerned will be at the table to work on soon.) I stated already in another email that tendering produces a lot of overhead and consumes a lot of TDF/community resources (and also extra money). Tendering also preclude TDF (and its staff / developers etc.) from gaining more knowledge about working on the source code etc. So the positive and interesting aspect in this subject is to find the areas where that is the case. And it's clear that those have been defined. And combining development and mentoring is also good for growing at least the developer base. Then the only discussion is: what is a sensible way to effectively manage in house developers/mentors. And, brushing in my opinion here: the combined knowledge of code, development, and existing needs, is best found in our ESC, with its broad composition, open meetings etc. It should be very clear that only TDF (board, ED) are managing the in-house developer. They are HR manager and the functional manager (maybe including some senior staff member). The ESC has no mandate to give any advise regarding their work or their area of work (in addition: if I look at the ESC meeting minutes I could not confirm that there is a real broad composition; seemed - beside TDF staff - only staff from three commercial companies attend the meetings usually). Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Cor, all, Am 01.06.22 um 11:48 schrieb Cor Nouws: Hi Andreas, Andreas Mantke wrote on 31/05/2022 19:49: I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in-house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control I do not understand what you mean. What is full control over open source code? it means control not over the source code per se, but over the direction of the development from a TDF point of view and the modules etc. TDF think are useful or needed by the community (and the user of the program and the donor). And this means TDF need to decide and operate independent from any commercial company. TDF with in-house developer could avoid a situation like the one with LOOL (I'm not sure that this opinion is common ground inside the current board). and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. It is indeed an interesting question to look at effectiveness of TDF-spendings. In case it is clear that in house development would result better work for the foundations goals, that is something we cannot easily ignore. (I would not be able to set some data there ;) ) But of course other aspects to consider there are: how can TDF be growing the ecosystem, which I think is one of the most important challenges of the LibreOffice project, and not compete with the ecosystem. (Different subject, that as far as I am concerned will be at the table to work on soon.) I stated already in another email that tendering produces a lot of overhead and consumes a lot of TDF/community resources (and also extra money). Tendering also preclude TDF (and its staff / developers etc.) from gaining more knowledge about working on the source code etc. So the positive and interesting aspect in this subject is to find the areas where that is the case. And it's clear that those have been defined. And combining development and mentoring is also good for growing at least the developer base. Then the only discussion is: what is a sensible way to effectively manage in house developers/mentors. And, brushing in my opinion here: the combined knowledge of code, development, and existing needs, is best found in our ESC, with its broad composition, open meetings etc. It should be very clear that only TDF (board, ED) are managing the in-house developer. They are HR manager and the functional manager (maybe including some senior staff member). The ESC has no mandate to give any advise regarding their work or their area of work (in addition: if I look at the ESC meeting minutes I could not confirm that there is a real broad composition; seemed - beside TDF staff - only staff from three commercial companies attend the meetings usually). 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] Merged proposal for in-house developers at TDF
Hi all, Am 01.06.22 um 11:11 schrieb Jan Holesovsky: Hi Andreas, Andreas Mantke píše v Út 31. 05. 2022 v 19:49 +0200: I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in- house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. Also when TDF switches targets, it has to pay for the time the developers have to spend learning the new area. On the other hand, the tendering is (and always has been) only budgeted from the excess, as the last thing after all the other costs (staff, marketing, infrastructure, etc. etc.) are covered - which gives TDF much more freedom in the planning: it can decide not to tender at all, if all the other costs give no room for that (and avoid hard decisions where to cut - infrastructure? conference? or even jobs?). I'm not sure if you're really thinking such simply or if you try to throw smoke grenades further. It seemed you try to create the impression that a contract of an in-house-developer is always for livelong and thus a big mandatory expense for a very long time. But I think you as the general manager of a commercial company should know better (?). The management of in-house developer is more lean and direct. Instead if you tender the development tasks you have to publish and advertise the tender, evaluate the bids, evaluate the milestones and the result(s). This is whole process consumes a lot of work time from TDF staff, board members and/or volunteers, which will be lacking in other important areas of the TDF/LibreOffice project then. Because a commercial company has to calculate in unforeseeable problems and realize a profit, the price for a tender is much higher. In addition the number of commercial companies, able to work on such LibreOffice source code tenders, is - spoken guarded - very clearly laid out. If we would see such 'diversity' outside of the TDF world we would name it a monopoly/oligopoly market and wouldn't expect a real competion. Over all I think the above answer shows that the role of a general manager of a commercial company, which has some interest in TDF tendering development, has a huge CoI with the TDF role(s). Thus I'd expect that this CoI should be solved asap and the appropriate measures taken to prevent TDF from further damage. 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] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke wrote on 31/05/2022 19:49: I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in-house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control I do not understand what you mean. What is full control over open source code? and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. It is indeed an interesting question to look at effectiveness of TDF-spendings. In case it is clear that in house development would result better work for the foundations goals, that is something we cannot easily ignore. (I would not be able to set some data there ;) ) But of course other aspects to consider there are: how can TDF be growing the ecosystem, which I think is one of the most important challenges of the LibreOffice project, and not compete with the ecosystem. (Different subject, that as far as I am concerned will be at the table to work on soon.) So the positive and interesting aspect in this subject is to find the areas where that is the case. And it's clear that those have been defined. And combining development and mentoring is also good for growing at least the developer base. Then the only discussion is: what is a sensible way to effectively manage in house developers/mentors. And, brushing in my opinion here: the combined knowledge of code, development, and existing needs, is best found in our ESC, with its broad composition, open meetings etc. 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] Merged proposal for in-house developers at TDF
Hi Andreas, Andreas Mantke píše v Út 31. 05. 2022 v 19:49 +0200: > I'd be curious to know what would be (from the point of TDF's mission > / > statutes) the difference between working on the source code by in- > house > developers and by tendering and paying a commercial company for doing > this work? > > I only could see the difference that in one case TDF has full control > and has not to pay for the benefit of a commercial company. And thus > in > the first case could get reach more targets / tickets done than in > the > latter case from my point of view. The difference is that once you hire a developer / developers, the development becomes a mandatory expense - TDF has to pay their wage every month. Also when TDF switches targets, it has to pay for the time the developers have to spend learning the new area. On the other hand, the tendering is (and always has been) only budgeted from the excess, as the last thing after all the other costs (staff, marketing, infrastructure, etc. etc.) are covered - which gives TDF much more freedom in the planning: it can decide not to tender at all, if all the other costs give no room for that (and avoid hard decisions where to cut - infrastructure? conference? or even jobs?). And obviously, for tendering, TDF should choose projects that fit the mission, no question about that. 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] Merged proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi wrote on 28/05/2022 11:25: The intention here (and I would very much like to support that idea), is to come up with a merged proposal, which then gets broad support. Broad support by whom? Up until Collabora Productivity's general manager came out with his own proposal there wasn't much effort being put in it by others in the board. This is an insinuation and specific framing, not fitting in "Please be helpful, considerate, friendly and respectful towards all other participants." There has been input from all sides over the past months, and you choosing the ones that are 'constructive' and not working with the ones you find not 'constructive'. We had that discussion before. You've been asked recently on this list to try to behave and respect the CoC. Please do try. If there's changes you believe are problematic, please interact with them. As above the changes makes it a completely different proposal, just rename it. Process-wise, my call to work out a proposal how to come to a joint text (in a small circle) is still open. I've asked many times but still no answer. Will you one day explain why you keep wanting to have this process behind closed doors? The proposal was not to have any process behind close doors (again an insinuation..) but to work with Kendy (iirc) to merge all ideas brought in the discussion so that there is one proposal to discuss. For 3 months there were no sides. The community contributed to the project and once it was ready the representative of a commercial contributor decided to propose a new document. Similar as above: an insinuation, negative framing and not true. 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] Merged proposal for in-house developers at TDF
Hi, Am 31.05.22 um 15:59 schrieb Jan Holesovsky: Hi Michael, Michael Weghorn píše v So 28. 05. 2022 v 21:21 +: (...) The following passage in that section is a bit unclear to me: It is also expected that while the Targeted Developer is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas. Can you clarify what that means in practice? Ah - it is the extension of the rationale how the development itself fits the TDF mission, ie. doesn't make that much sense without the previous paragraph that starts "Why is it important to major on mentoring". So how about: "Development per se is not part of TDF mission, but it is expected that while a mentor is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas." Does it make more sense this way? I'd be curious to know what would be (from the point of TDF's mission / statutes) the difference between working on the source code by in-house developers and by tendering and paying a commercial company for doing this work? I only could see the difference that in one case TDF has full control and has not to pay for the benefit of a commercial company. And thus in the first case could get reach more targets / tickets done than in the latter case from my point of view. But maybe I'm totally wrong and have no knowledge of the real market economy. 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] Merged proposal for in-house developers at TDF
Hi Michael, Michael Weghorn píše v So 28. 05. 2022 v 21:21 +: > I think having Paolo's original proposal and this one in a form > that's > easy to compare is very helpful. Thank you! > After reading the discussion on the mailing list, I was surprised > that > the overall direction still seems very similar to the one in Paolo's > unmodified proposal. Indeed - I'm trying to find the middle ground... > Removal of section "App stores management": As mentioned earlier, I > agree that it makes sense to separate the app store topic from the > current proposal of hiring developers, and focus on areas that are > currently not receiving enough attention otherwise. Please don't get me wrong - I believe the appstores is an important discussion, just don't want to block the hiring on that; as I think it is orthogonal to that. > Section "The solution: Hire a Targeted Developer": This sounds > mostly > good to me and if I understand correctly, also mostly fits with what > I > wrote earlier in the discussion. [1] > With the goal of improving areas that are neglected, having those > developers take responsibility for specific "oversight/target areas" > (by > either improving them themselves or by mentoring others) looks like > the > right approach to me, and it IMHO makes sense to focus on mentoring > others in case capable people interested in working on those areas > show > up. This way, TDF developers can potentially cover more areas over > time, > as work is shared. Perfect. > The following passage in that section is a bit unclear to me: > > > It is also expected that while the Targeted Developer is unable to > > actively contribute to public and professional education for > > whatever > > reason (eg. absence of volunteers) that they will be researching > > and > > increasing their experience by contributing to new ways to advance > > the > > free software and standards in their particular Target Areas. > > Can you clarify what that means in practice? Ah - it is the extension of the rationale how the development itself fits the TDF mission, ie. doesn't make that much sense without the previous paragraph that starts "Why is it important to major on mentoring". So how about: "Development per se is not part of TDF mission, but it is expected that while a mentor is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas." Does it make more sense this way? > Section "Selecting Target Areas": This sounds reasonable to me > (applying > a similar process to the tendering one and have ESC suggest, but BoD > ultimately decide on target areas). Great. > Section "Project management" has this: > > > The Targeted Developer will have the same rules, rights and > > conditions > > as any other volunteer or corporate contributor to the code under > > TDF > > umbrella. Overlaps or prioritisations that find no clear conclusion > > between the Targeted Developer and the ESC will be decided by an > > ESC > > vote, as is standardized for any overlaps in the development of the > > LibreOffice code, and applicable to all volunteer and corporate > > developers. For avoidance of doubt, by no means the Targeted > > Developer > > or TDF leadership by tasking the Targeted Developer can overrule > > code-related decisions as decided by the ESC. > > I completely agree to the first sentence. > > However, the part that ESC has the ultimate decision in case of > overlap > or prioritisation replaces one in Paolo's proposal where BoD would > have > the ultimate decision there. > > I think it would be in line with the previous section "Selecting > Target > Areas" if BoD would have the final say when it comes to > prioritisation > of target areas/tasks for the developer(s) (which I *thought* was > what > Paolo's proposal meant to say). > > In case of different opinions on a more technical level I'd > completely > agree that ESC should be the committee that would have the final > say, > just as is the case for any other contributor. (The last sentence > seems > to fit well with this.) > > As I understand it, your reply to Paolo [2] seems to be in line with > this, but can you please clarify this? Indeed, I should clarify this; I think changing "Overlaps or prioritisations that find ..." to "Technical decisions that find..." could do? > Section "Bootstrapping": > The initial proposal suggests to employ 2 developers, while the > modified > one suggests to "start with hiring a single Targeted Developer > initially, with the option to expand this to two if multiple > suitable > candidates present at the interview stage". > What's the practical difference of the initial proposal of planning > to > hire two developers (and then only employing one, if only one > suitable > candidate
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Paolo, all, Paolo Vecchi wrote: > On 27/05/2022 12:31, Thorsten Behrens wrote: > > Process-wise, my call to work out a proposal how to come to a joint > > text (in a small circle) is still open. > > I've asked many times but still no answer. Will you one day explain why you > keep wanting to have this process behind closed doors? > It was right there in one of my emails you were answering to; let me paste it: Thorsten wrote: > It is one option to make effective progress. As you state, it > appears that all people with an opinion have spoken up here; what's > now left to do, is to come up with a document, for which many (if > not all) directors can stand behind it. If community members like > Michael Weghorn or Michael Meeks would like to be part of that > working group, we should of course consider that, too. > What we ideally need, is *one* consolidated proposal. I'm grateful for Kendy taking the initiative, and starting one. > It's quite clear that there are 2 proposals now as the changes proposed > completely change the initial one. > Then lets please interact with the changes, such that we can iterate this to a single joint text. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Kendy, all, On 26/05/2022 17.08, Jan Holesovsky wrote: Good idea, Paolo, thank you. The new version that merges the proposals is in: https://nextcloud.documentfoundation.org/f/960049 as TDF-In-House-Developers-Proposal-v2.1.odt All my changes are change-tracked, so it should make the review easy. I've also removed some bits that are controversial, and OTOH not blocking the hiring. thanks for this. I think having Paolo's original proposal and this one in a form that's easy to compare is very helpful. When getting over this, I've primarily looked at the places for which change-tracking was indicating changes. Hope this fits the community needs? - comments much appreciated! Some notes/thoughts: After reading the discussion on the mailing list, I was surprised that the overall direction still seems very similar to the one in Paolo's unmodified proposal. Various changes look like they were mostly of a stylistic kind, or to formulate things in a less controversial way, without changing the proposal of what should be done. I haven't spent much time thinking about every single one of those in detail, but they look mostly reasonable to me. Removal of section "App stores management": As mentioned earlier, I agree that it makes sense to separate the app store topic from the current proposal of hiring developers, and focus on areas that are currently not receiving enough attention otherwise. Section "The solution: Hire a Targeted Developer": This sounds mostly good to me and if I understand correctly, also mostly fits with what I wrote earlier in the discussion. [1] With the goal of improving areas that are neglected, having those developers take responsibility for specific "oversight/target areas" (by either improving them themselves or by mentoring others) looks like the right approach to me, and it IMHO makes sense to focus on mentoring others in case capable people interested in working on those areas show up. This way, TDF developers can potentially cover more areas over time, as work is shared. The following passage in that section is a bit unclear to me: It is also expected that while the Targeted Developer is unable to actively contribute to public and professional education for whatever reason (eg. absence of volunteers) that they will be researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas. Can you clarify what that means in practice? Is the idea something like "Targeted developer should spend N % of their time on "education purposes", so if that time isn't spent on mentoring other contributors, let's find other ways to do so? (I think it definitely makes sense to get deeper into the topic and cooperate with other organizations and free software projects. I still think that the main focus should be to achieve practical improvements in LO. Depending on the target area, I can think of more or less way that this would naturally involve contributing to other free software projects etc, but - given limited resource - I personally wouldn't necessarily see contributing to other projects or doing research as a main goal by itself, at least not in the beginning.) Section "Selecting Target Areas": This sounds reasonable to me (applying a similar process to the tendering one and have ESC suggest, but BoD ultimately decide on target areas). Section "Project management" has this: The Targeted Developer will have the same rules, rights and conditions as any other volunteer or corporate contributor to the code under TDF umbrella. Overlaps or prioritisations that find no clear conclusion between the Targeted Developer and the ESC will be decided by an ESC vote, as is standardized for any overlaps in the development of the LibreOffice code, and applicable to all volunteer and corporate developers. For avoidance of doubt, by no means the Targeted Developer or TDF leadership by tasking the Targeted Developer can overrule code-related decisions as decided by the ESC. I completely agree to the first sentence. However, the part that ESC has the ultimate decision in case of overlap or prioritisation replaces one in Paolo's proposal where BoD would have the ultimate decision there. I think it would be in line with the previous section "Selecting Target Areas" if BoD would have the final say when it comes to prioritisation of target areas/tasks for the developer(s) (which I *thought* was what Paolo's proposal meant to say). In case of different opinions on a more technical level I'd completely agree that ESC should be the committee that would have the final say, just as is the case for any other contributor. (The last sentence seems to fit well with this.) As I understand it, your reply to Paolo [2] seems to be in line with this, but can you please clarify this? Section "Bootstrapping": The initial proposal suggests to employ 2
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi, On 27/05/2022 12:31, Thorsten Behrens wrote: Hi Paolo, all, Paolo Vecchi wrote: That document clearly contains another proposal which should go its own way instead of trying to make it pass as a "merged" proposal. The intention here (and I would very much like to support that idea), is to come up with a merged proposal, which then gets broad support. Broad support by whom? Up until Collabora Productivity's general manager came out with his own proposal there wasn't much effort being put in it by others in the board. If there's changes you believe are problematic, please interact with them. As above the changes makes it a completely different proposal, just rename it. Process-wise, my call to work out a proposal how to come to a joint text (in a small circle) is still open. I've asked many times but still no answer. Will you one day explain why you keep wanting to have this process behind closed doors? Having the two sides that are apparently the furthest apart, telling each other the text is not ok for the foreseeable future - is not my idea of a working process. For 3 months there were no sides. The community contributed to the project and once it was ready the representative of a commercial contributor decided to propose a new document. It's quite clear that there are 2 proposals now as the changes proposed completely change the initial one. Cheers, -- Thorsten Ciao Paolo -- 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] Merged proposal for in-house developers at TDF
Hi Paolo, Paolo Vecchi píše v Pá 27. 05. 2022 v 10:58 +0200: > Hiring-another-mentor-controlled-by-ESC-v1.0.odt is probably a more > indicated name for that new proposal. Hiring: yes. another-mentor: no; the proposal clearly says the primary role is development. + The secondary mentoring / sharing the knowledge sub-role is in line with the TDF mission, and only 'kicks in' when a volunteer in the area appears. + Rationale: when there are volunteers to work on the area, it is not an abandoned area any more, so it is better to use the donation money to bring the volunteers up to speed, and start focusing on the next Target Area. controlled-by-ESC: no; the proposal clearly says the Developer is managed by TDF, and the Target Areas are ultimately decided by the Board. + The role of ESC is important another way - it is necessary to avoid situation that the TDF in-house developer is "more equal" than the other developers; and the ESC is the only way how to make that happen. + Rationale: In the StarDivision times, we have already been in a situation when some developers were privileged, and it was hindering contribution both from volunteers and corporates. 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] Merged proposal for in-house developers at TDF
Hi Paolo, all, Paolo Vecchi wrote: > That document clearly contains another proposal which should go its own way > instead of trying to make it pass as a "merged" proposal. > The intention here (and I would very much like to support that idea), is to come up with a merged proposal, which then gets broad support. If there's changes you believe are problematic, please interact with them. Process-wise, my call to work out a proposal how to come to a joint text (in a small circle) is still open. Having the two sides that are apparently the furthest apart, telling each other the text is not ok for the foreseeable future - is not my idea of a working process. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Kendy, On 26/05/2022 17:08, Jan Holesovsky wrote: TDF-In-House-Developers-Proposal-v2.1.odt what you wrote in that document has completely changed the logic of the proposal so please do rename that file in something that relates better to its content. That document clearly contains another proposal which should go its own way instead of trying to make it pass as a "merged" proposal. Hiring-another-mentor-controlled-by-ESC-v1.0.odt is probably a more indicated name for that new proposal. Ciao Paolo -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Merged proposal for in-house developers at TDF
Hi all, Paolo Vecchi píše v St 25. 05. 2022 v 16:03 +0200: > Could you please at least rename the file so that people don't get > confused? Good idea, Paolo, thank you. The new version that merges the proposals is in: https://nextcloud.documentfoundation.org/f/960049 as TDF-In-House-Developers-Proposal-v2.1.odt All my changes are change-tracked, so it should make the review easy. I've also removed some bits that are controversial, and OTOH not blocking the hiring. Hope this fits the community needs? - comments much appreciated! 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
[board-discuss] Merged proposal for in-house developers at TDF
Hi all, Paolo Vecchi píše v St 25. 05. 2022 v 16:03 +0200: > Could you please at least rename the file so that people don't get > confused? Good idea, Paolo, thank you. The new version that merges the proposals is in: https://nextcloud.documentfoundation.org/f/960049 as TDF-In-House-Developers-Proposal-v2.1.odt All my changes are change-tracked, so it should make the review easy. I've also removed some bits that are controversial, and OTOH not blocking the hiring. Hope this fits the community needs? - comments much appreciated! 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
