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


Hi Michael,

Thank you for the feedback!  I've updated the document accordingly, see
below:

Michael Weghorn píše v Út 07. 06. 2022 v 14:07 +0000:

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.
[...]
In that regard, the "App stores management" section in Paolo's
updated 
proposal (v2.1) looks reasonable to me at first sight.

Makes sense, I've removed the deletion, the "App stores management" is
back.

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
mentoring".

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 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
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.

Thank you, I've added this as clarification.

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.

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.

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.

Applied.

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.

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.

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.

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?

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.)

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...)

OK, I've added the explicit list as examples.

Once again - thank you for your feedback!

All the best,
Kendy


--
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.