Re: [board-discuss] Re: In-house developers proposal v 2.1
Hi Paolo, Paolo Vecchi wrote on 08/06/2022 00:31: On 07/06/2022 21:40, Simon Phipps wrote: Kendy made a merged version and shared it with us all... No, once again he took my document and copy/pasted bits of Michael Meeks proposal on it to completely change the logic of the proposal. I assume if the 'logic changed', that is to reflect contributions in the discussion that were not added in your file. That proposal doesn't really fit with the budget planned, senior I think there is room to look to the budget for next year again, if needed. developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes. This is unhelpful framing. Influence is (apart from statutory limitations to participation from entities) from participating, which is done in the best traditions of open source development, which in the case of LibreOffice is broadened deliberately - I was at the discussion - to more than 'just' coding. The "legacy document" has actual contributions from many people of the community and TDf's team, the document on which Kendy pasted some text has only contributions from Michael Meeks and you Kendy made efforts to include comments and ideas from all sides. Very useful to come to a proposal with the broadest possible support respecting as much ideas as possible. greetings, Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Re: In-house developers proposal v 2.1
Hi Simon, On 07/06/2022 21:40, Simon Phipps wrote: Kendy made a merged version and shared it with us all... No, once again he took my document and copy/pasted bits of Michael Meeks proposal on it to completely change the logic of the proposal. That proposal doesn't really fit with the budget planned, senior developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes. It's really a waste of time to cherry-pick and update a legacy document instead of the one multiple people have been working on. The "legacy document" has actual contributions from many people of the community and TDf's team, the document on which Kendy pasted some text has only contributions from Michael Meeks and you (BTW please remove your only contribution as it names a potential supplier). 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] Re: In-house developers proposal v 2.1
Hi! Thanks for your calm reflections, Michael. On Tue, Jun 7, 2022 at 3:30 PM Michael Weghorn wrote: > > Looking at the diff between the 2 proposals: While there seem to be > different approaches in some bigger questions (like management, tasks of > developers), some seem to be more of a cosmetic nature. > Without knowing how the process works exactly: > While I don't really expect that there will be a consensus in all > aspects, I'm wondering whether trying to minimize the diff between the > proposals before doing a vote would be reasonable, so there's consensus > in as many aspects as possible. > Just to amplify this, I have been trying to contribute to this activity but having two (complicated) documents makes it hard to make contributions. Kendy made a merged version and shared it with us all and it would be really good if contributors could stick with improving that one and getting it to a state where there's maximum consensus between the directors (and hopefully the rest of us who are contributing but obviously Board agreement needs to be the priority. It's really a waste of time to cherry-pick and update a legacy document instead of the one multiple people have been working on. Cheers Simon -- *Simon Phipps* *TDF Trustee*
[board-discuss] Re: In-house developers proposal v 2.1
Hi Paolo, Kendy, all, On 30/05/2022 13.44, Paolo Vecchi wrote: After having read the other proposal I have integrated some minor changes into v 2.1 that you can find here: https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB Thanks for this, Paolo. Some comments: Some of the changes implemented: - added that TDF has increased its contributions also thanks to improved QA triage, UI and unit tests development - moved the "app stores management" section under Focus Areas and removed the long rationale behind the proposed focus area as it should be by now clear to all. It might be seen as controversial but it is a natural evolution to have the apps managed directly by TDF As written in my reply to Kendy [1] already: With the fact that the BoD has already decided that TDF will publish apps in the app store by itself, it seems to be less controversial to me to have that in the proposal as a potential target area/task for an internal developer. It is important from my point of view that a strategic proposal of this type does not contain artificial limitations for TDF to express itself fully in achieving its goals set in its statutes. While TDF is committed to working with members of the commercial ecosystem in a mutually beneficial relationship it should be made clear that third parties and suppliers (commercial contributors) should not limit what a charitable organisation can do as that is against our statutes and the principles TDF was created with. The ESC provides valuable contributions but it is well represented by commercial contributors and other external organisations which should not directly influence TDF's employees. Meetings with the ESC will provide useful exchange of information which will be evaluated by our mentors and our ED to take decisions as described in the proposal. Is that directed at Kendy's proposal? I either don't fully understand or don't share your concern that ESC would have too much influence there, since the "Selecting Target Areas" section in there says that each TDF member can suggest target areas. The ESC ranks those, but it's ultimately the BoD that decides. Given the BoD ultimately decides on the target areas, it's unclear to me how ESC would directly influence TDF's employees. Can you possibly explain that in a bit more detail? Looking at the diff between the 2 proposals: While there seem to be different approaches in some bigger questions (like management, tasks of developers), some seem to be more of a cosmetic nature. Without knowing how the process works exactly: While I don't really expect that there will be a consensus in all aspects, I'm wondering whether trying to minimize the diff between the proposals before doing a vote would be reasonable, so there's consensus in as many aspects as possible. Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00617.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 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] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Hi Andreas, all, On 30/05/2022 20.26, Andreas Mantke wrote: Do you think that the workflow used there would be worth sharing in more detail as something that might help in the TDF context as well? the key were / are not magical tools (we use a messenger and regular office file formats, e.g. pdf or odf etc.), but the people who drive it forward. It was important that there are two / three group members which lead the group and get the workflow running. This are managerial functions which I expect e.g. from the chairman / -women of a group. Thanks for sharing your experiences from another context. And I want to add another point: you can not always discuss papers and justify their text to the point where everyone is happy with it. You could not postpone decisions. It is better to decide promptly. Unanimity is not the key in the decision making process! I generally agree, but still think it makes sense to try to find consensus where possible, even if some controversial aspects will remain and not everybody will be happy with every single aspect of the final decision in the end. Best regards, Michael -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
