Re: [board-discuss] Another "merged" proposal of in-house developers
Hi Kendy, On 29/06/2022 10:00, Jan Holesovsky wrote: Can you please check the 2.3 once again, and merge those bits that are acceptable for you, and I'll see how can I rephrase the rest, so that we can finalize this, please? I was hoping that the extensive rationale I provided when I sent out version 2.2 of the proposal helped in understanding that it would have been very difficult to read a document where I had to remove a lot of text and move back a lot of sentences to bring it back to an acceptable version. In the version where you brought back in the text that in my opinion should not be there in the first place I've written many comments to help out in further understanding what I think is wrong with version 2.3. If we now take as a base the merged v 2.2 without all the problematic text you reintroduced then we should be much nearer to a finished document. 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] Another "merged" proposal of in-house developers
Hi Paolo, Paolo Vecchi píše v Po 27. 06. 2022 v 17:58 +0200: > The differences are not that many apart from those that I could not > accept as they impose limitations that have no place in an > employment > proposal. > > In the document v. 2.3 you just merged back the issues that will > cause > TDF to incur more costs and issues in finding the developers we need > so > we should not accept those changes- Unfortunately I am not sure which are those, and on the other hand, I hope there are still parts that are acceptable for you in the new form - where I've included eg. your paragraphs that explicitly say that the developers don't have to be senior and don't have to mentor from the day one, etc. Can you please check the 2.3 once again, and merge those bits that are acceptable for you, and I'll see how can I rephrase the rest, so that we can finalize this, please? 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] Another "merged" proposal of in-house developers
Hi Kendy, On 27/06/2022 17:38, Jan Holesovsky wrote: Thank you very much for that! I've once again rebased the changes on top of yours, but I see we are getting much closer; so in the TDF-In-House-Developers-Proposal-v2-3-Merged.odt I've accepted your changes where we both agree, to avoid confusion in change tracking, hope that's fine. The differences are not that many apart from those that I could not accept as they impose limitations that have no place in an employment proposal. In the document v. 2.3 you just merged back the issues that will cause TDF to incur more costs and issues in finding the developers we need so we should not accept those changes- If commercial contributors seek limitations on who employees should be and what they should do then the reasons should be made clear, they should be negotiated in public and should be valid for current and future commercial contributors. 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] Another "merged" proposal of in-house developers
Hi Paolo, all, Paolo Vecchi píše v St 22. 06. 2022 v 16:49 +0200: > as finally many of the changes requested by other proposals are clear > I've integrated what makes sense to have on a > developers recruitment proposal and added a few items clarifying > some aspect in version 2.2 (in ODF format) of this "merged" proposal > that you'll find here together with the other proposal: > > https://nextcloud.documentfoundation.org/f/960049 Thank you very much for that! I've once again rebased the changes on top of yours, but I see we are getting much closer; so in the TDF-In-House-Developers-Proposal-v2-3-Merged.odt I've accepted your changes where we both agree, to avoid confusion in change tracking, hope that's fine. Also it is good to see that we both agree that BoD has the ultimate deciding power; I think now it is mostly about finding the balance between the ESC and team, to make the conditions equal for all developers - internal, volunteer, or commercial. For those who don't have access to the TDF Nextcloud, here is a direct link: https://nextcloud.documentfoundation.org/s/pJLYLiH4m4HcjSN For those interested, I have also provided a change-tracked version of your document as TDF-In-House-Developers-Proposal-v2-2-Merged-Change-tracked.odt I am sorry I didn't find time yet to go through your below points one by one, happy to do that in a follow-up mail if needed. All the best, Kendy > What changed: > I've adapted a few sentences/words to get closer to the other > proposal where possible and eliminated some sentences/words > that might not add much to the context. > I've also reinstated the app store area as now is not controversial > anymore. > There is a specific paragraph stating that in-house developers are > not bound by ESC decisions. > > Overall the original logic is still there but showing a lower number > of differences to the other proposal. > > > What is still different: > The developers do not need to be senior or already capable of > mentoring, training them is part of our goals so we should do that > > The focus is clearly on the development side with mentoring to be > done when the developers are ready and willing > > There is less focus on the ESC handling the task and more on staff > dealing with it as developers are going to be part of TDF's staff so > they shouldn't be told what to do by non employees of TDF or the > Board. > > > What is not there: > The section related to "Targeted Developers" as it's a construct that > imposes limitations on what TDF's staff can do. We will employ in- > house developers that will work for the best interest of TDF and it's > wider community which initially will surely focus on specific areas, > the "Focus Areas", but over the years could cover other areas if they > like it and it's necessary. > > I believe that a candidate reading that an organisation is looking > for "targeted developers" might already feel the limitation of the > role and the lack of opportunities for personal growth so we might > prefer to welcome in-house developers that won't feel that > limitations as full members of TDF's staff. > > ESC deciding and having a final word on "overlaps in the development > of the LibreOffice code" is too broad as it might imply also > development related to projects, features or bug fixes on which a > third party might have interests expressed through the ESC which at > present has no CoI Policy. Limitations imposed on TDF's staff that > satisfy the interests/needs of third parties, or in some cases both > TDF and third parties, should be part of a separate agreement, not a > recruitment proposal. > > Other similar limitations, including non competition or development > of alternative implementation to (eg.) "Collabora Online, mdds, or > cppunit" have not been included in this version as they should be > covered by separate agreements which are independent to TDF's staff > recruitment. > > Contracts with subcontractors, trainers and specialists do not belong > in a recruitment proposal. Additional support or training will be > taken in consideration once we have evaluated the candidates and when > our mentors will inform us of what is necessary. > > Development contracts present in the other proposal will follow the > due tendering process. > > > I hope that the rationale for not including certain areas, terms and > limitations is clear to all in this "merged" proposal and that we can > proceed in finding great candidates to join our team as soon as > possible. > > 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] Another "merged" proposal of in-house developers
El 22.06.2022 11:49, Paolo Vecchi escribió: Hi all, as finally many of the changes requested by other proposals are clear I've integrated what makes sense to have on a developers recruitment proposal and added a few items clarifying some aspect in version 2.2 (in ODF format) of this "merged" proposal that you'll find here together with the other proposal: https://nextcloud.documentfoundation.org/f/960049 Those that don't have access to that folder or don't want to edit/comment it can access a PDF version from here: https://nextcloud.documentfoundation.org/s/BMnj2c4A9XR4oWk What changed: I've adapted a few sentences/words to get closer to the other proposal where possible and eliminated some sentences/words that might not add much to the context. I've also reinstated the app store area as now is not controversial anymore. There is a specific paragraph stating that in-house developers are not bound by ESC decisions. Overall the original logic is still there but showing a lower number of differences to the other proposal. What is still different: The developers do not need to be senior or already capable of mentoring, training them is part of our goals so we should do that The focus is clearly on the development side with mentoring to be done when the developers are ready and willing There is less focus on the ESC handling the task and more on staff dealing with it as developers are going to be part of TDF's staff so they shouldn't be told what to do by non employees of TDF or the Board. What is not there: The section related to "Targeted Developers" as it's a construct that imposes limitations on what TDF's staff can do. We will employ in-house developers that will work for the best interest of TDF and it's wider community which initially will surely focus on specific areas, the "Focus Areas", but over the years could cover other areas if they like it and it's necessary. I believe that a candidate reading that an organisation is looking for "targeted developers" might already feel the limitation of the role and the lack of opportunities for personal growth so we might prefer to welcome in-house developers that won't feel that limitations as full members of TDF's staff. ESC deciding and having a final word on "overlaps in the development of the LibreOffice code" is too broad as it might imply also development related to projects, features or bug fixes on which a third party might have interests expressed through the ESC which at present has no CoI Policy. Limitations imposed on TDF's staff that satisfy the interests/needs of third parties, or in some cases both TDF and third parties, should be part of a separate agreement, not a recruitment proposal. Other similar limitations, including non competition or development of alternative implementation to (eg.) "Collabora Online, mdds, or cppunit" have not been included in this version as they should be covered by separate agreements which are independent to TDF's staff recruitment. Contracts with subcontractors, trainers and specialists do not belong in a recruitment proposal. Additional support or training will be taken in consideration once we have evaluated the candidates and when our mentors will inform us of what is necessary. Development contracts present in the other proposal will follow the due tendering process. I hope that the rationale for not including certain areas, terms and limitations is clear to all in this "merged" proposal and that we can proceed in finding great candidates to join our team as soon as possible. Ciao Paolo It is quite clear that this is the version to take as a starting point as you have done a great job in putting together the various changes requested and makes text more clear. -- 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
