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

Hi Kendy,

On 10/06/2022 12.03, Jan Holesovsky wrote:
Thank you for the feedback!  I've updated the document accordingly, see

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
free software and standards in their particular Target Areas" means
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
job of a targeted developer is a bit different from the one outlined
your proposal, and more in line with Paolo's when there are no
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
Source projects actively maintained by LibreOffice volunteer or
corporate contributors."?

LOOL could be an example, but there is eg. the Kohei's mdds (that
essential for the Calc core), or Moggi's maintenance of cppunit -
hosted on freedesktop, but using LibreOffice bugzilla for

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,

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


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.