Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index


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+unsubscribe@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.