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

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
reason (eg. absence of volunteers) that they will be researching
increasing their experience by contributing to new ways to advance
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

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
one suggests to "start with hiring a single Targeted Developer
initially, with the option to expand this to two if multiple
candidates present at the interview stage".
What's the practical difference of the initial proposal of planning
hire two developers (and then only employing one, if only one
candidate shows up) and the new proposal?
Does this mostly mean that there will be no further job
once a first developer has been employed, or is there more to it?

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.

Section "Concerns expressed by the commercial contributors" has this
under 1):

TDF in-house developers will not compete with commercial
contributors and will not develop alternative implementations of
other Open Source projects.

IMHO, this is a bit too generic, since e.g. "developing (something
LibreOffice" could be seen as developing an alternative to, which is an open source project.

Very good point :-)

In case that was primarily directed at something specific (e.g. LTS
versions or LOOL): Can that be made more specific? (LTS is already
covered by 4), anyway.)

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.
Normally, I'd expect that there doesn't have to be any such phrase in the proposal after all, as my expectation would be that the BoD makes sure to select appropriate target areas that don't create a conflict.

Honestly, I don't see why TDF would reasonably want to start creating an alternative for/fork of mdds or cppunit. However, with the LOOL background, I understand to some extent that there's the concern to explicitly have some "clause" here. If necessary, my personal preference would be to have an explicit list of projects where there is actual concern right now (that can then be extended by BoD vote later as needed), because I think that in the hypothetical case case of a "malicious" volunteer or corporate contributor, the above clause could be misused in some way. (Writing this feels a bit odd, and I don't claim it's realistic at all and I hope it weren't needed, but I'm wondering whether strictly limiting the potential use of this clause makes sense to avoid confusion and help build a potential consensus...)

Best regards,


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.