Re: [board-discuss] Merged proposal for in-house developers at TDF

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