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

Reply via email to