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
