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
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.
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
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 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
modified
one suggests to "start with hiring a single Targeted Developer
initially, with the option to expand this to two if multiple
suitable
candidates present at the interview stage".
What's the practical difference of the initial proposal of planning
to
hire two developers (and then only employing one, if only one
suitable
candidate shows up) and the new proposal?
Does this mostly mean that there will be no further job
advertisement
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
in)
LibreOffice" could be seen as developing an alternative to
OpenOffice.org, 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,
Michael
[1]
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00610.html
--
To unsubscribe e-mail to: board-discuss+unsubscr...@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
