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

Hi Michael,

Michael Weghorn píše v So 28. 05. 2022 v 21:21 +0000:

I think having Paolo's original proposal and this one in a form
easy to compare is very helpful.

Thank you!

After reading the discussion on the mailing list, I was surprised
the overall direction still seems very similar to the one in Paolo's 
unmodified proposal.

Indeed - I'm trying to find the middle ground...

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.

Section "The solution: Hire a Targeted Developer": This sounds
good to me and if I understand correctly, also mostly fits with what
wrote earlier in the discussion. [1]
With the goal of improving areas that are neglected, having those 
developers take responsibility for specific "oversight/target areas"
either improving them themselves or by mentoring others) looks like
right approach to me, and it IMHO makes sense to focus on mentoring 
others in case capable people interested in working on those areas
up. This way, TDF developers can potentially cover more areas over
as work is shared.


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?

Section "Selecting Target Areas": This sounds reasonable to me
a similar process to the tendering one and have ESC suggest, but BoD 
ultimately decide on target areas).


Section "Project management" has this:

The Targeted Developer will have the same rules, rights and
as any other volunteer or corporate contributor to the code under
umbrella. Overlaps or prioritisations that find no clear conclusion
between the Targeted Developer and the ESC will be decided by  an
vote, as is standardized for any overlaps in the development of the
LibreOffice code, and applicable to all volunteer and corporate
developers. For avoidance of doubt, by no means the Targeted
or TDF leadership by tasking the Targeted Developer can overrule
code-related decisions as decided by the ESC.

I completely agree to the first sentence.

However, the part that ESC has the ultimate decision in case of
or prioritisation replaces one in Paolo's proposal where BoD would
the ultimate decision there.

I think it would be in line with the previous section "Selecting
Areas" if BoD would have the final say when it comes to
of target areas/tasks for the developer(s) (which I *thought* was
Paolo's proposal meant to say).

In case of different opinions on a more technical level I'd
agree that ESC should be the committee that would have the final
just as is the case for any other contributor. (The last sentence
to fit well with this.)

As I understand it, your reply to Paolo [2] seems to be in line with 
this, but can you please clarify this?

Indeed, I should clarify this; I think changing "Overlaps or
prioritisations that find ..." to "Technical decisions that find..."
could do?

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.

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.

All the best,

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.