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
