Re: [DISCUSS] Re: [board-discuss] [VOTE] New proposal for hiring in-house developers.
hi Jean-Baptiste, On 02.12.22 19:21, Jean-Baptiste Faure wrote: Hi Thorsten, If the ESC is an official TDF committee, where are its statutes, its functioning rules and the rules of its members designation ? hmm i've wondered this too a while ago, i couldn't find a word in the TDF statutes about it :) If it is an official TDF committee, why its mailing list is not hosted by TDF ? due to the fact that it pre-dates the founding of TDF - it exists as long as the LibreOffice project - its mailing list is hosted on freedesktop.org. the address is: libreoff...@lists.freedesktop.org probably migrating the mailing list wasn't considered worth the hassle to subscribers? apparently it was called "tech steering" in the beginning? or at least the minutes claimed that was the name? h... the oldest minutes i can find also seem to abbreviate "action item" as "AA:" - that was still the case when i joined, those were the days :) no, found an even older minutes mail - the first one says "technical group" - dated 2010-09-28. https://lists.freedesktop.org/archives/libreoffice/2010-September/02.html (in case you want to send a mail to all ESC members, sorry but i don't know any more convenient way than to manually put them into the address field in your mail client...) regards, michael -- 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
[DISCUSS] Re: [board-discuss] [VOTE] New proposal for hiring in-house developers.
hi Stephan, On 02.12.22 11:12, Stephan Ficht wrote: Dear board, hi all, = Foreword: I here speak in my capacity as a Member of the Board of Trustees. = This part of the vote TDF will seek to hire a developer(s); - who will report [...], and consult weekly with the ESC, which will oversee the technical direction of the work; is in my opinion not acceptable. This results in TDF (the employer) paying for the staff but others will have the saying about their tasks. how is this different from TDF employees Cloph, Heiko, Hossein, Ilmari, Olivier, Stéphane, Sophie, and Xisco, who already consult weekly with the ESC? regards, michael -- 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
[board-discuss] the importance of shepherding this list & TDF
Hi there, On 29/11/2022 23:38, Franklin Weng wrote: > Believe me or not. Let me try to provide a quick counter-balance in this thread. It seems to me extraordinary to criticize Thorsten like this for doing his job - in line with the best practices for communications as adopted by the board[1] on this list. We badly need our E-mail discussion to get more focused and respectful. Blunt finger pointing: "I don't trust >that person<" seems radically non-constructive to me. Surely better to work on the real issue - ideally one to one first (or bring a friend along if you're concerned about that), then in a larger group if that doesn't work out, before bringing it to everyone (ideally on tdf-internal). I would like to read a lot less E-mail attacking the person not the ball. I'd also like to see a lot less public board posturing - it has reached a ridiculous level. We have a board director claiming in public that other directors support his proposal, which then multiple directors point out that they in fact don't, before them saying again that they actually do etc. It seems like the Christmas pantomime season complete with comedy audience contradictions has come early =) The huge volume of E-mail on these topics doesn't help anyone. I think it is safe to assume that wiser counsel is rather restrained when sending E-mail, and that many read this and think it better not to feed the flames - apologies if I do that here. We elect a board to hammer out compromises - ideally these arrive well formed and in a way that commands support or acquiescence of the whole board. In cases where that is impossible then some split vote and ideally a principled objection E-mail, and closing the topic seems wise. We don't elect a board to amplify division & to escalate even uncontroversial topics (such as hiring two staff members) into some apparent existential nightmare of posturing to try to 'win' at all costs. It is good to decide topics and move on. I'd like also to try to remove some of the poison here with a personal take on Thorsten, with whom I've worked on & off for ~twenty years. I don't like unqualified "I trust", or "I don't trust" people - partly because I don't trust myself in some situations[2]; it seems to me a polarizing loss of nuance. Also - I trust even my political opponents to be generally decent citizens. However my sphere of trust for Thorsten is abnormally large. Thorsten is someone that TDF is extremely blessed to have in our community; he has contributed in an overwhelmingly positive way to LibreOffice and at significant scale. I don't always agree with him - and I compete with him in the marketplace (as well as partnering) - but his integrity is something I can rely on. His patience when dealing with controversy, his balance and desire to find a workable solution is legendary. More than that - we are a statutory meritocracy - and Thorsten has contributed an incredible amount of do-ing to the project not just coding (and apparently cloning himself[3] =) - but innumerable small acts of kindness and nurturing behind the scenes. He repeatedly encourages me to think that: "everyone is really just trying to do what they think is best" when I loose faith in that. Oh - and did I mention his positive input on the ESC, serving from our founding on the Board, doing the jobs that no-one wanted to eg. as an example all the donation book-keeping for many years - which was done with great probity. Did I mention his personal investment in allotropia - which contributes lots of LibreOffice code - this could go on and on but this E-mail is already an example of the over-long E-mails we have on the list and I just got started. Let me summarize it this way: Thorsten rocks. If anyone plans to attack and/or exclude him from TDF - they better bring a large-ish team of people to try to replace the immense good he does here. TDF needs good people to shepherd the board, and also this mailing list. It will perhaps be no surprise that I also have received constructive feedback on improving my tone on the list privately from Thorsten: that's his job - it's mine to take that to heart. Let me encourage others to listen - and act likewise. Against that - if people believe they are being harassed - they should report that privately to the CoC committee who will investigate that sensitively without fear or favor - there is no tolerance for harassment no matter how senior and important the people involved. Regards, Michael. [1] - https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05644.html and I quote: - If we should find ourselves in a strong disagreement with another person, we make our responses to each other via private messages rather than continue to send them to the list or the group. If we
Re: [board-discuss] Report about numbers from Apple App Store
On 23/11/2022 17:22, Andreas Mantke wrote: You try to mislead the audience a bit here. I see no evidence of that from Thorsten. It's not a 'donor' but a business entity from the eco system. And it is not a donation but a business deal. I've been criticized for many things, but being criticized in relation to Collabora's donations to TDF is a newish one =) Please stop repeatedly mis-characterizing our donations. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Agenda for TDF board meeting on Monday, October 31st at 1800 Berlin time (UTC+1)
hi Andreas, On 29.10.22 22:07, Andreas Mantke wrote: In additon: I reviewed the whole process about sending a project to the attic again. The proposal for the process seemed to neutral text, but it was only written and voted on for one subproject: LOOL. The only four members, which participated in the vote and agreed on the proposal, had all a CoI on the LibreOffice Online topic, except one. The three members had to stay away from the discussion and decision on this proposal, because of their CoI. Thus there were only one effective participation and vote on the proposal. Thus the proposal was not approved. Conclusion: there is also no approved basis for topic 7. but why do you stop at this step? if i count correctly, of the directors that approved various versions of the CoI policy, a majority of them either have subsequently restricted their actions due to potential CoI, or there is an investigation for potentially having a CoI ongoing at the moment. following your line of argument that the policy applies to decisions that lead to decisions where the policy applies, it's clear that none of them should have participated in discussing or voting on the CoI policy, since all of them have an obvious CoI with the CoI policy because it could potentially restrict their actions, and therefore the CoI policy has never been properly accepted for lack of quorum (4 directors). [board-discuss] [VOTE] Approve version 1.3.2 of the CoI policy https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05506.html of 6 votes, 4 were by directors with potential CoI [board-discuss] [VOTE] Approve version 1.3.1 of the CoI policy https://www.mail-archive.com/board-discuss%40documentfoundation.org/msg05130.html of 5 votes, 3 were by directors with potential CoI in both cases, only 2 directors who don't have an interest in the CoI policy participated in the vote. best regards, michael -- 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
[board-discuss] Updated Code of Conduct - blind-sided
On 06/10/2022 12:39: > Hi everyone, > > The Document Foundation has updated its Code of Conduct, the set of > guidelines that explains to our contributors and users what behaviours > and interactions we value: > > https://www.documentfoundation.org/foundation/code-of-conduct/ It is deeply disappointing to me that in a community committed to transparency - the first time I see or have input into this text is when it is published as law. This despite having done the work as half of the CoC committee for the last many years, and having helped to tweak and introduce the previous compromise policy. How did we fail that hard ? When we last did a CoC change we had wide discussion and input from many perspectives. We had a talk with feedback from the Rome conference (we had a perfect opportunity to do the same only days ago in Milan - was that deliberately missed?). When this appeared on the board agenda I asked about it privately to Sophie and the directors, and got nothing. Previously we had a carefully balanced pair of people: Bubli (later Sophie) and myself chosen to give confidence to any reporter and/or person reported against that they might have someone that can empathize with their perspective - so we could (ideally) achieve a quiet resolution, reconciliation and quickly restore peace, reducing escalations. That had minor tweaks over time. In contrast - it seems that this policy has been written in secret has a large volume of novel text and lots of quirks - eg. being based on an obsolete version of the Contributor Covenant for no obvious reason (the newer 2.1 is unsurprisingly better). I've not, as yet, had a chance to fully read the text, but the process so far needlessly burns my trust in the balance of the result. As the only coder on this new CoC committee (and having been unilaterally volunteered by others to enforce something I've not had a chance to read) - I'm seriously considering my position. Unfortunately it is not the first time that this approach has been used which I can characterize as: * a small group plans & drafts in secret * it decides not to include known interested or affected people around the topic * public / wider discussion and input is avoided * it suddenly dumps a big chunk of new rules on the community * no time is allowed for input * there is a rush to vote against an imposed deadline This has been used before to give really poor results and to significantly re-shape the community. There appears to be no reason for things to be done in this way. It is a really unfortunate way to work that damages trust. It also appears to conceive of those with different views as being fundamentally the problem - to be excluded - rather than a resource to collaborate with to make something widely acceptable to everyone for the good of TDF. This is a particularly wasted opportunity - because a new CoC (with which I have no problem in principle[1]) can give a useful point to reset our discourse as a community and to draw a line under some of the past unhelpful behavior. An opportunity for a fresh start from a new place that improves some of our interactions. Basing that on the trust re-built in-person at the conference is a great idea in principle. However - bouncing this through, in this way, without notice or discussion looks extremely rude. It is not how a community I'm happy to be part of should behave. It is far from inclusive. Perhaps when I have more calm & space - I'll try to work out if there is any genuine willingness to engage with improving the text. From a quick skim some details look quite problematic. In general there is substantial scope for mis-use (or even just the damaging appearance of it) around CoC enforcement and we need to build confidence that we will get this right. At a bare minimum I would expect each individual behind this, -particularly- if they are on the new CoC committee, to at least -try- to repair the situation by re-assuring the community that (despite apparently excluding people & views during the process of creating and pushing this initiative through) - that when actually enforcing the CoC they will respectfully listen to all views and act in an inclusive and balanced way. Regards, Michael. [1] - the latest Contributor Covenant is rather less problematic than in the past -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Disappointing trademark pieces
ould focus its time on un-blocking TDF investment of donor's money into real feature/function improvement to make the positive changes in the code we all know are needed, which have been budgeted, and for which we have more than enough funding. Interestingly Sun transferred to themselves the OpenOffice.org trademark back in 2008 which generated widespread concerns around how that could be (mis-)used against contributors. Sun managed to sort things out without reaching this level of dispute AFAIK, indeed I've yet to see a complaint from (even competitors) tackled in this way. We would ask the TDF board to pick a direction and stick with it, get this confusion sorted out, improve its processes as above, to speak with a consistent voice and to focus on executing on its mission. It is sad to me that this sort of change consumes a non-trivial amount of Collabora resource that should be focused on powering the FLOSS development we love and which benefits all LibreOffice users. Disappointedly, Michael. [1] - https://dashboard.documentfoundation.org/ [2] - https://listarchives.documentfoundation.org/www/board-discuss/2020/msg00691.html https://nextcloud.documentfoundation.org/s/Z6Y2YeDKHoRW3s8 [3] - https://www.collaboraoffice.com/press-releases/collabora-office-22-05-introduces-new-features-and-performance-enhancements-combined-with-excellent-interoperability/ [4] - eg. search for 'Performance' https://wiki.documentfoundation.org/ReleaseNotes/7.2 https://wiki.documentfoundation.org/ReleaseNotes/7.3 https://wiki.documentfoundation.org/ReleaseNotes/7.4 [5] - https://www.zdnet.com/article/torvalds-weighs-in-on-linux-trademark-row/ [6] - https://wiki.documentfoundation.org/TDF/Policies/Trademark_Policy [7] - https://www.mail-archive.com/board-discuss@documentfoundation.org/msg06010.html -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Merging Of Contributions
What a silly thread.
Some neutral name for the integration should be picked and
implemented and/or both names be accepted; I would suggest 'lok'
for LibreOfficeKit. Commit/revert wars are a nonsense that helps
no-one - I would expect the ESC should intervene and cut out the
politics.
There are of course three big problems in computer science:
naming things, and off-by-one errors - so it's no real surprise.
On 01/09/2022 19:44, Paolo Vecchi wrote:
I guess it's hard to spot a cool among many lool but then
we'll have to notify all developers...
LibreOffice is much cooler than you think; cf. the appended.
Michael.
$ git grep lool
i18npool/source/localedata/data/om_ET.xml: Onkoloolessa
$ git grep cool
canvas/workben/canvasdemo.cxx://TODO: do something cool
extras/source/autocorr/lang/en-AU/DocumentList.xml:
extras/source/autocorr/lang/en-GB/DocumentList.xml:
extras/source/autocorr/lang/en-US/DocumentList.xml:
extras/source/autocorr/lang/en-ZA/DocumentList.xml:
extras/source/autocorr/lang/ja/DocumentList.xml:
extras/source/autocorr/lang/ko/DocumentList.xml:
extras/source/autocorr/lang/zh-CN/DocumentList.xml:
extras/source/autocorr/lang/zh-TW/DocumentList.xml:
filter/source/svg/presentation_engine.js:
window.webkit.messageHandlers.cool !== undefined)
filter/source/svg/presentation_engine.js:
window.webkit.messageHandlers.cool.postMessage('EXITSLIDESHOW', '*');
oox/source/drawingml/shape3dproperties.cxx:case XML_coolSlant: return
"coolSlant";
oox/source/token/tokens.txt:coolSlant
readlicense_oo/license/CREDITS.fodt: http://wiki.documentfoundation.org/User:Maahicool; text:style-name="Internet_20_link"
text:visited-style-name="Visited_20_Internet_20_Link">Maahicool (1)
reportbuilder/java/org/libreoffice/report/pentaho/output/ImageProducer.java:
// cool, the file exists. Let's try to read it.
sd/source/filter/html/htmlex.cxx:// Exceptions are cool...
sfx2/emojiconfig/emoji.json:"cool": {
sfx2/emojiconfig/emoji.json:"name": "squared cool",
sfx2/emojiconfig/emoji.json:"shortname": ":cool:",
solenv/inc/mime.types:x-conference/x-cooltalk ice
sw/source/core/doc/tblrwcl.cxx:// It *is* sometimes cool to have
multiple tests/if's and assignments
sw/source/filter/ww8/ww8scan.cxx:Otherwise our cool fastsave algorithm
can be brought to bear on the
sw/source/filter/ww8/ww8scan.cxx://Store old end position for supercool new
property finder that uses
vcl/unx/generic/print/common_gfx.cxx:// cool, we can concatenate
rectangles
writerfilter/source/dmapper/TextEffectsHandler.cxx:case
NS_ooxml::LN_ST_BevelPresetType_coolSlant: return "coolSlant";
writerfilter/source/ooxml/model.xml: coolSlant
writerfilter/source/ooxml/model.xml: coolSlant
writerfilter/source/ooxml/model.xml: coolSlant
writerfilter/source/ooxml/model.xml: coolSlant
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Board of Directors Meeting 2022-07-11
On 15/07/2022 12:11, Stephan Ficht wrote:
### Public Part
1. Answering questions from the community (tdf-board, 5 mins)
Rationale: Provide an opportunity for the community to ask
questions to the board and about TDF
Let me add my questions as I asked them (and as I pasted them to the
chat channel of the board meeting at the time) and an answer as I heard it:
1. How much cash does TDF have in the bank ? (Michael)
~Eur 2,700,000 -> some of it dedicated to tasks (Thorsten?)
free reserve in excess of Eur 500,000
2. When will TDF meet its obligation to pay badly overdue bills
for contractors & what is the impact on TDF's ability to
deliver on tasks ? and/or blocking of tendered tasks such
that others don't do them either ?
* TDF cash? (Michael)
* what about paying tenders? Timeline?
* don't know details (Laszlo)
* what is blocked? (Michael)
* issues to be solved (Paolo)
* at least any timeline? (Thorsten)
* will have answer soon, but not this/next/following week (Paolo)
* new tenders seemed to be blocked (Thorsten)
* doing our best to unblock situation (Paolo)
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] re-discovering the Foundation roots?
On 04/07/2022 17:54, Paolo Vecchi wrote: On 04/07/2022 18:22, Uwe Altmann wrote: I'm willing to prepare and moderate a session (similar to the one in Brno) If there is some interest within the community because it doesn't make sense to do this with three to five Persons new at the project as we had in Rome. Thank you for that Uwe =) I for one would be interested to attend your session if I can. I believe it's important even if only the board is present as I have the impression that there are different views that are sometimes the cause of conflicts in the interpretation of what TDF should or should not do. Its unusual that I agree with Paolo, but the above is I think unarguable. - the duty of the member of the board to take decisions for the benefit of TDF and not third parties Sounds interesting - I'd love to explore whether TDF's primary goal is to serve its own economic purposes (eg. growth in assets, more donations etc.) or rather to serve whichever of its non-profit goals the Board of Directors decides has priority at any given time. But either way, sounds like a discussion worth having, ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Work On Update LOOL (was Re: LOOL is about to be archived)
Hi Andreas, On 24/06/2022 16:51, Andreas Mantke wrote: I'm not sure, if you as a former Collabora staff member don't any potential CoI in the whole topic. I'm pretty sure though =) László hasn't worked with Collabora since 2017 and AFAIK has no (even indirect) commercial relationship with us since then. If working together at the same company with someone creates a five+ year CoI - then we have an issue, because large numbers of core LibreOffice developers have enjoyed working with each other at different companies over the years from Sun and Novell/SUSE onwards. In fact - it's wonderful that the community has managed to retain as many passionate and competent developers and keep their institutional knowledge for this time. It is perhaps more amazing that the ecosystem companies have managed to keep paying jobs for them: go LibreOffice! I'd prefer if only community members without potential CoI share their opinion on this topic. Clearly opinions can differ without anyone needing to be paid. For my part I'd like to pay a quick tribute to László - there is really a lot to say - much more than I can fit in a paragraph. László has contributed a huge amount to LibreOffice, not just the 700+ code commits[1], but also authoring our hunspell spell checker infrastructure (László has helped spell-check much of the web too via Mozilla & Chrome ;-). He authored our Lightproof grammar checker, the Hungarian spell checking dictionary, and don't let me forget LibreLogo - what better mix of TDF's educational purpose and promoting LibreOffice =) as well as being a long-term TDF member, working for FSF.hu, NISZ and perhaps more. Did I mention what a positive and thoughtful contributor to discussions he has been too - and what a wide experience of different FLOSS projects he has ? =) Thanks for all you do László =) Accusations of CoI can be extremely divisive, it is not a small thing to baselesly suggest inappropriate behavior - to shut someone down. I also have no idea why it's not possible to work on a common ground of LOOL (LibreOffice Online) and why it is/was instead necessary to fork the code away from the LibreOffice community and rename it. This is covered as a FAQ: https://collaboraonline.github.io/post/faq/#own-project Projects are all different - as you point out. Some go through periods of turmoil and strain and then come out of them again - I'm really hoping that LibreOffice can re-focus and move on constructively. Regards, Michael. [1] - https://www.libreoffice.org/about-us/credits/ -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Kendy, On 10/06/2022 12.03, Jan Holesovsky wrote: Thank you for the feedback! I've updated the document accordingly, see below: Thanks a lot! 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. [...] 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. Re-reading the sentence now with those changes in place, I'm wondering whether I just previously misunderstood what was meant: Is "researching and increasing their experience by contributing to new ways to advance the free software and standards in their particular Target Areas" actually the part that includes working on LibreOffice code? If so, the prioritization makes total sense to me as is. (I was previously assuming that this is yet another activity besides doing direct mentoring and the development task, something that would be done to have a larger "mentoring" share of some kind if there weren't "enough" mentees at hand, and I didn't really understand what that would be in practice, so wondering whether it would be justified to spend resources on that.) 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. Thanks, looks good to me. 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? Looks better to me already. What I had in mind was an explicit list, something like: "TDF in-house developers will not compete with commercial contributors and will not develop alternative implementations of the following Open Source projects actively maintained by LibreOffice volunteer or corporate contributors: Collabora Online, mdds, cppunit" [add more here if more are an area of concern] 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.) Sounds good. Thanks again, Michael -- 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
[board-discuss] A thank-you to our app-store publishers.
Hi there, Paolo Vecchi wrote on 31.05.22 at 21:03: TDF to publish LibreOffice in the app stores, especially Apple and Microsoft. TDF will work to prepare LibreOffice for the app stores as soon as possible As this era ends, I'd like to say how pleased we are at Collabora to have been able to lead here - to have fronted the significant initial investment needed to get LibreOffice into the Mac sandbox, and app-store and to have got it done. We made it easier for a large number of users to get LibreOffice. Later on we charged for the convenience and re-invested that into improving the Mac version up-stream, and also are pleased to have donated a significant sum to TDF. We've also explored the market-demand-curve for convenience, updated the board from time to time & will of course complete that (as time permits) when the situation settles. I'd like to thank many for their great work here: Tor Lillqvist in particular, but also Tomaz Vajngerl, Lubos Lunak, Andras Timar & Miklos Vajna. It is also important to give credit and thanks to CIB & Allotropia for their work on getting a high quality LibreOffice into the Windows app-store to make it more accessible to people too. I'm not sure that I have the exact list right here but I'd like to call out Marina Latini, Vasily Melenchuk, Samuel Mehrbrodt and Thorsten Behrens for making the goodness happen. Looking back at this app-store journey, we have a debt of gratitude particularly to Simon Phipps, Nicholas Christener, Uwe Altmann and Marina Latini for their hard work around building better ways to structure the app-store provision. There are many views on that - but it is unarguable that they put in a lot of hard work and love to try to improve LibreOffice which is much appreciated. I'd like also to give credit to the PortableApps team for making LibreOffice available in their app-store. They have done great work promoting us from early in the LibreOffice project: https://www.libreoffice.org/download/portable-versions/ Paolo Vecchi wrote on 31.05.22 at 21:03: TDF to publish LibreOffice in the app stores ... Which leads us to other app-stores. Traditionally packaging has been a great provider of diversity and excellence around contribution to LibreOffice - starting IIRC with Frederic Crozat's amazing work to make OpenOffice.org into the first Mandrake Linux packages waaay back in the day - which much of our Linux packaging is ultimately built on. Anyhow - it was wonderful to have lots of work from Stephan Bergman and Caolan McNamara at RedHat with help from Robert McQueen at Endless to get LibreOffice into: https://flathub.org/ "Flathub - An app store and build service for Linux". As always getting LibreOffice into a different kind of sand-box sounds trivial, and yet often takes quite some work. Then of course we have the team started by Bjoern Michaelsen who massaged LibreOffice into the nattily named "Snap Store" - https://snapcraft.io "the app store for Linux with an audience of millions." thanks for making that happen Bjoern! And thanks too to Olivier Tilloy, Heather Ellsworth, Rico Tzschichholz, Marcus Tomlinson for their patient tending and improvement of the snap app! I should mention William Gathoye for his great work making LibreOffice available in Chocolatey - though at some stage I start to get fuzzy as to what is, and is not an app-store. Going wider we've been blessed by many sympathizers mutually promoting LibreOffice and their brands in software catalogs left and right. Anyhow. Lots of good work, much of it already working and build-able on without immediate bit-rot I hope. If the TDF board want to have a bigger packaging team, so be it. Hopefully it will not negatively impact those who previously did the work. I am somewhat curious as to the budget impact here, and the real scope of "app-store". In particularly how much time is this expected to take away from areas such as CTL/RTL, CJK as well as other things that we are hoping to address with targeted developers ? I'm also curious if the plan is for TDF to sell LibreOffice (in app-stores or elsewhere) and to become a for-pay vendor. Presumably there is no need to decide immediately on that but I look forward to the conclusions and rationale over the next month. Apologies to those that my memory inevitably missed out, and go LibreOffice! All the best, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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://listarch
Re: [board-discuss] Re: In-house developers proposal v 2.1
Hi Paolo,
On 08/06/2022 09:18, Paolo Vecchi wrote:
That is a copy/paste from a text the general manager of a commercial
contributor sent the 23/05
It is not the greatest vote of confidence in your position that you
critique the source of a counter-proposal rather than the proposal
itself: please play the ball not the man.
You then go on to (again) mis-characterize Kendy's merged proposal,
something you've repeatedly done and been corrected on:
developers mostly focused on mentoring are very difficult to find and
very expensive, and anyone with basic HR skills would never let
employees be managed by a committee in which third party companies
have can have so much influence as seen in recent minutes.
The proposal contains this:
"The Executive Director shall direct day to day management for
the Targeted Developers to ensure they effectively focus on the
Target Areas."
Line management is up to the ED - that is explicit. I suspect that they
will not direct management by a committee - but it's up to them =)
Attempting to exclude targetted developers from attending the ESC call
and reporting on what they're up to - as they become respected peers
alongside others working on the code seems extraordinary.
Again your understanding of how LibreOffice development and the ESC
works seems weak as I've outlined before[1].
Regards,
Michael.
[1] -
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00557.html
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] Re: In-house developers proposal v 2.1
Hi Paolo, Kendy, all, On 30/05/2022 13.44, Paolo Vecchi wrote: After having read the other proposal I have integrated some minor changes into v 2.1 that you can find here: https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB Thanks for this, Paolo. Some comments: Some of the changes implemented: - added that TDF has increased its contributions also thanks to improved QA triage, UI and unit tests development - moved the "app stores management" section under Focus Areas and removed the long rationale behind the proposed focus area as it should be by now clear to all. It might be seen as controversial but it is a natural evolution to have the apps managed directly by TDF As written in my reply to Kendy [1] already: With the fact that the BoD has already decided that TDF will publish apps in the app store by itself, it seems to be less controversial to me to have that in the proposal as a potential target area/task for an internal developer. It is important from my point of view that a strategic proposal of this type does not contain artificial limitations for TDF to express itself fully in achieving its goals set in its statutes. While TDF is committed to working with members of the commercial ecosystem in a mutually beneficial relationship it should be made clear that third parties and suppliers (commercial contributors) should not limit what a charitable organisation can do as that is against our statutes and the principles TDF was created with. The ESC provides valuable contributions but it is well represented by commercial contributors and other external organisations which should not directly influence TDF's employees. Meetings with the ESC will provide useful exchange of information which will be evaluated by our mentors and our ED to take decisions as described in the proposal. Is that directed at Kendy's proposal? I either don't fully understand or don't share your concern that ESC would have too much influence there, since the "Selecting Target Areas" section in there says that each TDF member can suggest target areas. The ESC ranks those, but it's ultimately the BoD that decides. Given the BoD ultimately decides on the target areas, it's unclear to me how ESC would directly influence TDF's employees. Can you possibly explain that in a bit more detail? Looking at the diff between the 2 proposals: While there seem to be different approaches in some bigger questions (like management, tasks of developers), some seem to be more of a cosmetic nature. Without knowing how the process works exactly: While I don't really expect that there will be a consensus in all aspects, I'm wondering whether trying to minimize the diff between the proposals before doing a vote would be reasonable, so there's consensus in as many aspects as possible. Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00617.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
Re: [board-discuss] Merged proposal for in-house developers at TDF
s 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
Re: [board-discuss] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Hi Andreas, all, On 30/05/2022 20.26, Andreas Mantke wrote: Do you think that the workflow used there would be worth sharing in more detail as something that might help in the TDF context as well? the key were / are not magical tools (we use a messenger and regular office file formats, e.g. pdf or odf etc.), but the people who drive it forward. It was important that there are two / three group members which lead the group and get the workflow running. This are managerial functions which I expect e.g. from the chairman / -women of a group. Thanks for sharing your experiences from another context. And I want to add another point: you can not always discuss papers and justify their text to the point where everyone is happy with it. You could not postpone decisions. It is better to decide promptly. Unanimity is not the key in the decision making process! I generally agree, but still think it makes sense to try to find consensus where possible, even if some controversial aspects will remain and not everybody will be happy with every single aspect of the final decision in the end. Best regards, Michael -- 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
Re: Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
hello Paolo, On 02.06.22 19:55, Paolo Vecchi wrote: > > Also thanks to Andreas comment about the ESC minutes I had a look at > last week and today's minutes and it seems like Michael Meeks is already > implementing his proposal, transposed mostly by copy/paste by Kendy in > his own proposal (which BTW hasn't been renamed yet), with some > unexplained urgency and without anyone informing the board. if memory serves (and i'm sorry to say i missed last week's meeting due to a public holiday), the ESC discussed this topic because there was an urgency expressed on this list [1] regarding the hiring of in-house developers/mentors by TDF. one of the questions with this plan is which problem domains the in-house developers would be working on, that is, which are the areas that are actively used but under-maintained currently, so that for example expertise in such areas could be considered when evaluating applicants. hence the question was brought to the ESC to draw on the experience of its members in diverse areas of the code base, and the ESC attempted to come up with a list of such under-maintained areas in a collective effort, in order to expedite the TDF hiring process. the current version of the list, imperfect and unfinished as it is, is public in the TDF Wiki. also there was a follow-up discussion on the public mailing list, with about half a dozen people with various backgrounds - including several community members who are not in the ESC - provided additional input that can been taken into account. in case the board no longer considers hiring to be urgent, or is not interested in advice prepared by the ESC and sourced from the developer community, i think the ESC (who i don't speak for, this is just my personal opinion) would be most happy to stop discussing this topic and come back to it at a later date; please advise us of your preference in this regard. best regards, michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00540.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
Re: [board-discuss] Merged proposal for in-house developers at TDF
ction "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? (Given that the section mentions that this will be re-evaluated after a year, I personally don't have a strong opinion on this either way, but if the budget to employ two targeted developers is there, I'd see no need to limit this to one.) 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. 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.) Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00209.html [2] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00563.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
Re: [board-discuss] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Hi Andreas, On 25/05/2022 22.57, Andreas Mantke wrote: I have worked together with a group of people on documents during the last 1.5 year. The documents were not in an editable (e.g. ODF) format. But everyone, who want to improve one of the documents, was able to contribute and improve the documents. The format of a document didn't hinder anyone to submit a valuable proposal / addition. I want to add that this group was not made out of developers, but common office workers. Do you think that the workflow used there would be worth sharing in more detail as something that might help in the TDF context as well? My impression is that there seems to be no clear process of how to work together on a proposal, how to suggest changes,... It seemed to be a new territory to work on a proposal / document in public on a mailing list. Doesn't the BoD have any defined process for doing so? (If somehow working together on the ODF version or talking to each other in person is no option: From a developer's perspective, having the proposal as plain text in a git repo and then allowing people to suggest changes and the "proposal owner" reviewing those sounds like one way that would allow to keep track of suggestions, but that may not be easily usable for non-developers. Having a plain text version being discussed on the mailing list and the proposal owner answering there and integrating changes into the authoritative version sounds like an alternative that might work instead, while having some more overhead. But there are probably other ways...) If you discuss about addition to the document on the mailing list and add them to a document in another place, you have a media segregation. This makes a work on the document not easy and some will loose track and will quit to contribute further. And if you'd use git for such a document you will only cover a small part of the LibreOffice/TDF community. The non-devs will likely not able to submit their input within a git repo. Very true. I'd be very interested to hear whether/how those problems were avoided when cooperating in the group of people you mentioned above. Best regards, Michael -- 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
Re: [board-discuss] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Hi Paolo, thanks for your reply. On 25/05/2022 11.54, Paolo Vecchi wrote: While I am generally in favor of Paolo's proposal, I share the impression that various concerns or suggestions have not been dealt with adequately so far. For example: Michael has asked for an ODF version of the proposal so that he could suggest changes and he pointed out some specific issues he saw in the proposal e.g. in [1]. Unless I'm missing something, he didn't receive any reply to that (at least none on the public mailing list) and at a quick glance, (most of) the mentioned passages are still unchanged in the current version of the proposal. You are right, I did not provide Michael Meeks an ODF version as I wanted this process to be transparent for all. I've asked from the beginning for everyone to make their proposals in board-discuss so that everyone would see what changes were being requested. [...] As you can see if Michael Meeks wants to propose something he can do it even without having an ODF at hand. Regarding his suggestions he may have not noticed that in page 10 there the proposal has been updated nearly 2 weeks ago: https://nextcloud.documentfoundation.org/s/sfJeNq7H9GS8YPe Thanks for mentioning this once again, I hadn't read all emails in the threads once again before writing my previous email. However, as far as I can see, even that version still doesn't address all of the aspects that Michael mentioned in his email [1]. For illustration what I mean, let me give two examples: 1) Even v2 still uses the different formulations throughout the document on how and by whom the developers are managed and tasked, as Michael Meeks pointed out in his email. While I wouldn't say those are completely contradictory, unifying that across the document seems reasonable to help avoid potential confusion. 2) Michael wrote: Other pieces surprise me by still being there eg. :"Commercial contributors confirm that tenders issued by TDF : form a negligible part of their income" which seems to refer to this from his previous email [2]: "Collabora publishes numbers on this at the conference each year - between 0% and 5% of income depending; but still, 5% is not insignificant." But still, the sentence is in v2 of the proposal just the same. That was for illustration; I see no need to discuss these points in detail in this thread here. I think it makes sense to rather base further discussion on the diff between your version 2.0 and Kendy's suggested changes in what he called version 2.1. That "version 2.1" touches the above aspects as well. Whether it does so in the "correct way" is certainly something that is worth discussing if there is disagreement. My impression is that there seems to be no clear process of how to work together on a proposal, how to suggest changes,... Doesn't the BoD have any defined process for doing so? There are processes we follow for some areas. Other areas can and should be in the open so that the community can participate and see how the proposals are being influenced. My presumably too naive expectation was that there would already be a working process to work together on a proposal within the BoD (how modifications would be suggested and integrated,...), and it might be possible to do similarly in public as well, e.g. by just writing the emails discussing the proposal on the public mailing list (in addition) or sharing a link to an editable document or some tool with more people (maybe with just read permission for non-BoD members). As above it seems like some processes are not working as they should and we haven't yet implemented the right tool for this specific job which should give a voice also to non developers. Having a clear process for this that would allow everybody to contribute actually sounds like a huge step forward to me, seeing there was quite some confusion in the current discussion and it seems that there were different expectations even among BoD members on how contribution was supposed to take place. [3] If there are different opinions/interests then, IMHO, the best thing to do is to make them public so that our community can express their own opinions. I agree with that, and hopefully discussing the different opinions/proposals now will help everybody understand the underlying reasoning/motivation better. Now we can clearly see that a member of our community and representative of a commercial contributor prefers to have mentors instead of developers. I have the impression that the wider community prefers to have actual developers so, which voice should we follow? As mentioned above, I think it makes sense to continue that discussion in the other thread on Kendy's so-called "merged proposal" (version 2.1). I'll reply on that thread later. Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/20
[board-discuss] Hiring Targeted Developers ... feedback.
Hi everyone, Thanks for all the contributions here. Let me try to summarize things and look for the common ground here: * TDF hiring one (or two) developers This is a common factor - apparently, as was expressed at the beginning of this thread - this is not that controversial. We both want to get new people working on some of the most important under-loved areas in LibreOffice, and ideally quickly. Shrinking the proposal to a minimal set that doesn't include controversial things seems to me the best way to get quick action. A constructive proposal was asked for - and I provided one. Hopefully it can attract some support & the board / TDF can move to executing on it quickly. * Senior developers and mentors are very similar I'm fairly convinced that any developer that TDF should employ should be able to work constructively in our community - which means good communication skills, ability to compromise, and to be able to explain complex technical concepts to persuade other community members around their chosen direction / solution. These seem to me to be nearly the same soft skills we want from a mentor. Open Source development is not and should not take place in ivory towers where developers can work without significant social interaction with others. Indeed to become a senior (as Thorsten suggests) lots of this collaborative behaviour is expected even in closed projects. Software is in large part about people ultimately (for better or worse). So - I think any senior software engineer would be able to do both this job and more focused development tasks; so not a huge divergence. I really think, given our mission, if we have volunteers that are eager to work in an area, and need mentoring it would be altogether better on every axis to get them deeper into the project and help them succeed rather than paying to do the same thing ourselves in isolation. * Some areas of disagreement with Paolo: On 25/05/2022 14:51, Paolo Vecchi wrote: You may notice that the difference is that I believe that the 2 new members of the team should be managed by our mentors and our ED. My proposal: https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05723.html leaves that decision to the ED - they should focus on execution: "The Executive Director shall direct day to day management for the Targeted Developers" - if they want to do that via other mentors - that's up to them. Michael Meeks' prefers to have the ESC controlling the mentor/developers I think this is the same mis-understanding about how the ESC behaves as some command & control body instead of a co-operate & persuade thing. I wrote a little about that here: https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05667.html But I struggle to see how you get "controlling" out of: "Targeted Developer(s) (as normal dev-mentors) shall attend the ESC call, and report on their progress weekly in the normal way." or was it somewhere else ? but, while I value their technical input, it's a body that is very well represented by commercial contributors employees. I do not think it's a wise idea to have TDF's employees being directed/controlled by our own suppliers. Apart from the mis-understanding about what being present and reporting on progress in a transparent, weekly group of peers open to anybody means, this is extraordinary to me. Can you expand on your concern here ? who are "our own suppliers?" can you define the problem there in more detail ? I believe my proposal retains a good balance which has served us well over the years: of the ESC advising the board on engineering matters, the board deciding a course of action, and the ED/staff executing on that. Perhaps clarifying a counter-proposal and rationale for it would help. * Conclusion I would commend the board to getting rapidly to the point where we can hire one to two developers (depending on applications) who can also be mentors (ie. my proposal) - since this is the kind of person we want in the project. I'd also suggest - to the points about it being hard to hire good developers (and it really is!), that we dedicate some budget to advertising widely. I'd also suggest that we look in and/or around academia - where (I guess) people who are competent and like learning and teaching tend to lurk. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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://l
Re: [board-discuss] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Hi Andreas, all, On 24/05/2022 23.09, Andreas Mantke wrote: I follow the thread(s) about hiring two in-ho use developers by TDF for some month yet. I got the impression that there are some TDF members which might have no real interest in getting this task done. They are asking only questions and didn't submit any solutions or proposals for solutions. And once all valuable input from TDF members had been incorporated in the document the beforehand mentioned members try to start the whole process with a new proposal. It seemed there is a approach behind this behavior: postpone the whole topic as far as possible. And try to frustrate the members who try to drive this topic forward. I agree that it is frustrating to see what is going on and to get the impression that it seems to be impossible to work together on a common proposal. Obviously, I am not able to judge what each one's motivation is. However, from following the discussion so far, I don't think it is fair to blame only "one side" for the state of affairs. While I am generally in favor of Paolo's proposal, I share the impression that various concerns or suggestions have not been dealt with adequately so far. For example: Michael has asked for an ODF version of the proposal so that he could suggest changes and he pointed out some specific issues he saw in the proposal e.g. in [1]. Unless I'm missing something, he didn't receive any reply to that (at least none on the public mailing list) and at a quick glance, (most of) the mentioned passages are still unchanged in the current version of the proposal. Obviously, I can't speak for him, but I could at least understand to some extent in case he felt unheard and that doing an own counter-proposal would be the only way of his suggestions not just being ignored completely... My impression is that there seems to be no clear process of how to work together on a proposal, how to suggest changes,... Doesn't the BoD have any defined process for doing so? (If somehow working together on the ODF version or talking to each other in person is no option: From a developer's perspective, having the proposal as plain text in a git repo and then allowing people to suggest changes and the "proposal owner" reviewing those sounds like one way that would allow to keep track of suggestions, but that may not be easily usable for non-developers. Having a plain text version being discussed on the mailing list and the proposal owner answering there and integrating changes into the authoritative version sounds like an alternative that might work instead, while having some more overhead. But there are probably other ways...) In my opinion the whole process and the behavior of beforehand mentioned members is not in the interest of TDF. If that would be the way how members will work together during the current board term the future of TDF will not be bright. Again, I wouldn't limit that to the "beforehand mentioned members", but to the (at least perceived) inability to work together constructively when there are different opinions. Quoting from a previous email of mine in one of the threads [2]: In my previous email, I wrote: "Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all." I admit that this will probably be very hard if members of the involved LibreOffice/TDF bodies don't find a way to work together constructively, but rather "fight against each other". But I think that's a problem on a completely different level, and I don't see how TDF can properly serve it's purpose then anyway, regardless of the specific question around TDF-internal developers being discussed here... Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00357.html [2] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00209.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
[board-discuss] Hiring Targeted Developers ...
Hi everyone, Let me try to provide a simpler proposal that combines several ideas from the thread and focuses on clarifying the management aspect. Hopefully as an E-mail it is easier to interact with the content. * Rationale A selection of points from Paolo's discussion on the list: * As shown by Italo's slides at FOSDEM again and by others, TDF is not contributing code as much as it could * Members of the ecosystem and others also suggested that we should spend more money to grow development * certain topics such Target Areas as accessibility and RTL/CTL can be harder to taken care of by volunteers without help, and are not always addressed by the ecosystem * We need to build up skills and development capabilities to speed up innovation and diversify the LibreOffice community. * So I propose: * Hire a Targeted Developer, with primary focus on mentoring Why is it important to major on mentoring: TDF has an educational mission -and- we want to grow and diversify our volunteer community. Training existing and new contributors in specific areas can accelerate our mission, grow capability in these Target Areas, while also addressing functional gaps in LibreOffice. It is also expected that while the 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. In addition to direct mentoring they can document related code, publish and speak at related conferences in these spaces and educate the public on the relevance, capabilities and mission of LibreOffice to encourage cooperation with other organizations that pursue, at least partially, the same goals. * Selecting Target Areas The process of selecting Target Areas to apply additional development resource to is one that is potentially highly contentious. It is vital that we have a clear, transparent and capable process to do this. It is important that TDF stewards its limited resources well, and does not invest in areas that are already well resourced, or to crowd out 3rd party funding. So: * Any TDF member can identify a suitable high-level Target Area such as RTL, complex-text, or accessibility. * The ESC will rank such areas as an addendum to the existing budget ranking process, and exceptionally during bootstrapping. The full ranking and votes will be published * The Board (who bear the ultimate decision) will select suitable areas for Targeted Developer(s). Such mentors to be in addition to existing generalised mentors. * Day to day management Targeted Developer(s) (as normal dev-mentors) shall attend the ESC call, and report on their progress weekly in the normal way. To maximise benefit to LibreOffice ESC members can privately disclose any live / credible overlaps with their work in sub-areas without having to disclose full details of potential or pending business in this area. Such specific sub-areas will be avoided for a time. The Executive Director shall direct day to day management for the Targeted Developers to ensure they effectively focus on the Target Areas. * Bootstrapping The ESC should be encouraged to identify and rank some suitable Target Areas rapidly. This shall allow the Board to agree them, and a hiring process with skills targeted at these areas to commence post haste. TDF should 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 - and evaluate the process after a year. It is expected that it will be hard to find a senior developer with all the needed skills from the day one. The tendering group inside the Board should tender for a suitable amount of mentoring hours from several senior certified developers, to help to get the newly hired Targeted Developer(s) up-to-speed. -- michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot -- 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
[board-discuss] Re: Drafting Tender "Improve the accessibility checker for PDF/UA"
Hi, On 17/05/2022 18.03, Olivier Hallot wrote: I have updated the tender document with the valuable inputs received. My gratitude to C. Strobbe, S. Mohn and T. Vajngerl for their comments. The tender document file is now https://nextcloud.documentfoundation.org/s/Gxw82TWcCWiXRBq for more comments and advise. Sorry for being a bit late. I like the proposal. The introduction is very informative and provides the necessary background knowledge. It also gives a differentiation between 2 parts: 1) "First is to enable PDF/UA support into PDF export, which writes a PDF/UA flag into the PDF document and enables all the required features." 2) "an accessibility check functionality, which traverses the document structure and gathers all possible accessibility issues" However, I'm a bit confused about the exact scope: Not being a native English speaker, I would have understood the later section "Scope out of this Tender" as "Out of scope for this tender", i.e. "not to be done as part of this tender". Is that correct? If so, my understanding would have been that the tender mostly covers aspect 2) from above, but not actual PDF export, since the "Scope out of this Tender" section contains this: "Development and bug fixes to the PDF export module (pdfium or equivalent), related to the PDF/UA-1 standard." But then, it seems to me that issue tdf#148934 listed in the "LibreOffice Upstream fixes" section would presumably require improving PDF export as well. The same might be true for the requirement that exported documents should pass veraPDF validation (mentioned in section "Acceptance criteria"), unless the set of features used in the sample documents (the ones listed in section "PDF/UA checks"?) is guaranteed to already be covered by the current PDF export implementation just fine. Can that possibly be clarified? (Maybe I just misunderstand something.) Depending on the exact scope of this tender, we could also consider making PDF export issues part of the "Fix accessibility issues" tender scheduled for this year: https://wiki.documentfoundation.org/Development/Budget2022#Fix_accessibility_issues Which brings me to Heiko's earlier message in this thread: On 11/05/2022 09.36, Heiko Tietze wrote: I wonder why the other tickets from META bug 139007 are excluded (btw, there is kind of duplicate META bug 101912 with a lot more). [...] Three weeks seems underestimated if we expect to solve all issues. The general a11y meta bug 101912 depends on the PDF a11y meta one, bug 139007. Therefore, dependencies of bug 139007 are listed in the tree view for bug 101912 as well: https://bugs.documentfoundation.org/showdependencytree.cgi?id=101912_resolved=1 Given that, I think it makes sense to add PDF a11y bugs as explicit dependencies for bug 139007 only. (They'll be shown as transitive dependencies for bug 101912 anyway then.) Best regards, Michael -- 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
[board-discuss] Re: Proposal for in-house developers at TDF
On 12/05/2022 13:29, Paolo Vecchi wrote:
after receiving quite a few comments and suggestions it seems like is
time to publish
...
I have received no additional constructive feedback from the board since
the last published version so I assume
...
I'd really love to get some answers to my points from March,
perhaps you took those on-board, let me link to those:
https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05550.html
"The concern around clarifying management and tasking of the proposed
new staff is still there. I link my original comment which seems to still be
unaddressed. Having ten people manage two is a problem as we know from
previous boards."
etc.
Interesting that mail links to the unaddressed issues from Feb,
let me link to that, though it is perhaps obsoleted by the former.
https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05477.html
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Drafting Tender "Look-ahead styleref field for Writer"
On 06/05/2022 14:42, Regina Henschel wrote:
I thought, ODF is the basic file format for LibreOffice. So I expect,
that writing in 'ODF extended' format is included in the tender anyway.
Sounds sensible to me =) of course, the ball-parks are very often done
quite quickly finger-in-the-air things not a hard and fast rule -
estimation can be expensive.
I'd suggest just including Regina's ODF bits into the spec. seeing what
comes out of the tender price-wise; I particularly like your text Regina
about not having to block on the ODF TC. That could prolly be helpfully
tweaked to require only a single "reasonable" implementation of this for
the ODF filter.
ATB,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] A big thank-you to the ESC ...
ay all your key-strokes fall in pleasant places. With warmest regards, Michael. PS. couldn't quite resist a culturally jarring top-post =) On 28/04/2022 12:14, Stephan Ficht wrote: > 2. Discuss & vote: Update ESC composition (Kendy, 5 mins) > > The ESC has agreed to update its current composition: > > https://www.documentfoundation.org/governance/engineering-steering-committee/ > this way: > Lionel Elie Mamane (Individual) → Vasily Melenchuk (CIB) > Andras Timar (Collabora) → Luboš Luňák (Collabora) > Michael Meeks (Collabora) → Tomaž Vajngerl (Collabora) > Olivier Hallot (TDF) → Ilmari Lauhakangas (TDF) > Sophie Gautier (TDF) → Hossein Nourikhah (TDF) > Katarína Behrens (Individual) → Andreas Heinisch (Individual) > > There is one swap of an individual contributor to a corporate > contributor, but it is the only CIB person on the list, so the > corporate affiliation rule still stays maintained. > > The ESC kindly asks the Board to approve this change. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] certification list issue ?
Hi Andreas, On 14/04/2022 14:38, Andreas Mantke wrote: On 09/04/2022 13:17, Andreas Mantke wrote: > https://www.documentfoundation.org/gethelp/developers/ you see ...>> > And if you make a small research inside the git log, you'll find out > that the list at the website is not up to date. There seemed to be > further certified developers, stated as unaffiliated, which are > working for the company (with an appropriate account). Which you seemed to avoid substantiating too. I would really appreciate you either clarifying and reporting something actionable there, or withdrawing this statement which seems to suggest something underhand is going on when it is not. If you look into the git log you find the developer email: muhammet.k...@collabora.com Thanks for reporting this - it is really easy to put it to rest. You'll see the last commit to core from 2021 like this: Author: Muhammet Kara Date: Sun Aug 22 03:24:25 2021 +0300 Was his contract with Collabora canceled recently? If I don't overlooked it, his Collabora email address is not listed on the LibreOffice git page, you linked in a former post: https://git.libreoffice.org/gitdm-config/+/refs/heads/master/domain-map Good point; Muhammet moved on to do new things from August 31st 2021 (~9 months ago) - I believe he notified people of that and the developers page was updated so it is accurate. We should prolly tweak domain-map as you say but it's not hyper-urgent, worst case we may double count people vs. a commit with a new address - do submit a patch if you like. You mentioned "further developer/s/ stated as unaffiliated" - anyone else there ? it's good to put any uncertainty and doubt to rest here. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] certification list issue ?
Hi Andreas, Let me re-pose the questions that perhaps you missed here: On 09/04/2022 13:17, Andreas Mantke wrote: > https://www.documentfoundation.org/gethelp/developers/ you see > that most of them are contracted by Collabora. Which seemed inaccurate to me, and: > And if you make a small research inside the git log, you'll find out > that the list at the website is not up to date. There seemed to be > further certified developers, stated as unaffiliated, which are > working for the company (with an appropriate account). Which you seemed to avoid substantiating too. I would really appreciate you either clarifying and reporting something actionable there, or withdrawing this statement which seems to suggest something underhand is going on when it is not. ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] certification list issue ?
Am 09.04.22 um 08:51 schrieb Heiko Tietze:
If you take me as an external observer, the opposite is true.
Collabora is home for many experts, every single one always
supportive, and never acted against the interests of the project.
Thank you for your kind words Heiko - much appreciated.
On 09/04/2022 13:17, Andreas Mantke wrote:
it's great to have a lot of certified developer, which are able to work
on LibreOffice. But if you have a look on e.g.
https://www.documentfoundation.org/gethelp/developers/ you see that most
of them are contracted by Collabora.
A quick count shows 20/57 - around a third - which doesn't seem
unreasonable.
And if you make a small research
inside the git log, you'll find out that the list at the website is not
up to date. There seemed to be further certified developers, stated as
unaffiliated, which are working for the company (with an appropriate
account).
Interesting, this "list is not up to date" is a novel problem.
Quite possibly our affiliation database etc. is out of date, and indeed
keeping the certified developer list up-to-date takes time & effort, but
- I'm struggling to see who you are talking about. Collabora has a
commercial interest in having as many certified developers listed as
possible - rather than hiding them =)
For those interested in the minutia can see:
https://git.libreoffice.org/gitdm-config/+/refs/heads/master/domain-map
That is already not very simple - but in some cases it's more
complicated than a straightforward affiliation; eg. you will see rather
rare examples like:
commit 828504974d70111e4a35b31d579cf42fe660a660
Author: Armin Le Grand (Collabora)
Date: Fri Feb 21 16:58:17 2020 +0100
tdf#130768 speedup huge pixel graphics Cairo
but actually:
commit 9c526b557e264280cb0c9da704245494f5ec5af3
Author: Armin Le Grand (Allotropia)
Date: Fri Mar 4 16:51:07 2022 +0100
Advanced Diagram support: Allow reLayout without keeping oox::Shape
Armin is working with Allotropia ~all the time. I don't think that need
concern anyone - many contractors have the (important) liberty to do
work for other people from time to time.
But ... ? I'm not aware of a significant inaccuracy overall.
As a general comment though - if you find a bug: that's normal please
help us fix it by improving whatever list it is you're worried about
with a clear bug report. I didn't manage to see that with a small
research of my own - can you help ?
Thanks !
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] Dividing & excluding ...
Hi there,
Since it seems that there are only complainers on one side of
this discussion let me give another view. If only to avoid the idea
that there should be major concessions on one side only.
I am thrilled that three of our founding team: Kendy, Thorsten
& Cor are on the board, and fully engaged in the discussions - they
(along with some of the other board members plus of course deputies) -
bring as individuals a huge depth of experience, competence, and a
decade+ of service each to LibreOffice. They are reasonable, friendly
and like-able people who are working for the best of TDF. From what I
have seen their approach to political discussion and compromise is to
be reasonable, winsome, to look for what is possible for the good of
TDF & LibreOffice.
I see excluding such representatives of the Trustees from
fundamental matters (such as budgeting what topics to spend money on,
how to structure and run TDF etc.) as in conflict with our statutes.
Such decisions by statute ($8.1) are to be taken by the whole
board, which stands together for damages: I suppose I agree with
Andreas on this. Any CoI policy is for a specific interest - clearly
no director should vote on the conclusion of a transaction with
themselves ($9.6) - that is reasonable: but the fundamental decisions
are for the whole board - and budgeting is the explicit task ($8.2) of
the board of directors as they fulfill the will of the founders and
mandate of the members.
Again - it is important that our CoI policy is not used
maliciously to subvert democracy by excluding directors from their
main statutory tasks. If this new policy is being mis-used for this it
should be significantly amended in this regard; it was not the
intention when it was created.
So - let me vigorously complain as a Trustee: that those for
whom I voted are being encouraged to exclude themselves from the very
things that they were elected to do. The very idea that we should
exclude some of our most competent is grim for TDF - particularly when
Thorsten, Kendy, Cor, Gabor represent over 50% of the first-choice
votes for board members. The will of those Trustees should be
reflected our budget.
Worse - since TDF uses tenders to complete what it needs to
spend each year (something we are very badly behind at at last check
with Eur ~2.5 million in the bank) - it is easy to argue that any
decision with a spending aspect either increases or decreases the
remaining pool for tendering.
Using that fact to try to exclude anyone whose employer might
(independent of them) submit a bid for a tender - from any spending
related board decision (which is most of them) is grim. I've seen this
argument aired here recently.
It means tearing up the votes from Trustees for those people,
while walking all over our statutes.
TDF really needs competent suppliers to bid for its tenders -
and we could use more entities applying there, not fewer.
TDF really needs competent, friendly, welcoming, helpful
people to stand on its board and represent its Trustees - we have only
just about enough.
TDF already has a firewall to avoid self dealing. It has a
fair and completely opaque (to those bidding) process for choosing who
wins. It has a process for selecting and estimating tasks that is open
to all ideas - and is promoted by TDF itself. The ESC ranks ideas -
and the primary problem in the past there has been chasing ESC members
to do the work to evaluate and rank the proposals. The ESC ranking is
typically provided with full details of who voted whatever way to the
board, then the board takes this into account as it ranks this in the
budget.
There is no corruption here.
Although - it can appear that this talk of conspiracy &
malfeasance is primarily an attempt to overturn the will of the
Trustees as reflected in the election results.
Not every board member or Trustee is going to like every
proposal - I would suggest that a "take it or leave it" approach to
improving such proposals is deeply counter-productive.
We go no-where good fast when we turn to attacking the
motivations of those who want to improve any proposal instead of
working together collaboratively to improve things.
So lets stop this nonsense for the good of TDF.
Lets engage with critiquing the issues and proposals, and not critique
the people who are trying hard to do a good job on the board.
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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.d
Re: [board-discuss] New draft of the proposal for in-house developers
Hi Franklin,
On 25/03/2022 14:26, Franklin Weng wrote:
we have seen something like "why do you think we (C*a) would want to
help you in creating a competing product?" when someone asked for help
in our developer's IRC channel.
I'm flattered by what I assume is this new C*a contraction of Collabora
=)
Collabora helps its competitors every day - primarily by contributing
tons of code to LibreOffice that they can use. Also by working
collaboratively with other engineers from competing companies. We give
feedback, advice and help on the code - as we do for volunteers -
typically in some rough proportion to their estimated contribution.
We're somewhat less sympathetic to silly questions (RTM) or to attempts
by others to leech our time away to support their needs & customers
without contributing meaningfully (as/when/if that happens).
As I regularly say: working on the LibreOffice code is fun - and I'd
really recommend actively contributing to the code to everyone so they
can get a real feel for how that works first-hand.
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] Re: New draft of the proposal for in-house developers
Hi Julien, thanks a lot for the input! Michael PS: I've fixed Lionel's email address now, something went wrong when I copy-pasted it into my previous email. On 25/03/2022 09.18, Julien Nabet wrote: Hello, Here are some thoughts about Base. Some years ago, there was some decision to reduce our Java dependency (a very good thing). Main point was to replace HSQLDB part by another database (there are good ones like MySQL/MariaDB and Postgresql) but which also allowed embedding, with a compatible license and with a not dead community, so Firebird was chosen. In addition to Lionel (who is the Base expert for those who don't already know it), there have been 2 people who mainly worked on it: Andrzej J.R. Hunt and Tamas Bunth. The last one had even implemented a tool to migrate automatically from HSQLDB to Firebird. Andrzej left Firebird part long time ago and Tamas left some years after him (just to be clear, I see no pb here, each one has his life/constraints/desire/whatever) In parallel, Firebird has been put "in production" as by default embedded database and automatic migration set as by default. A lot of bugtrackers have been created and even if some part has been fixed, there were too much. So I first put in experimental automatic migration part then Firebird by default + creation part (you can still open a Firebird embedded in non experimental). Now we use HSQLDB 1.8 which is quite old and Firebird support is not ready, the pb is Lionel has far less availability and there's no one who replaced him. I gave a try to tackle some bugs but I'm not brainy enough to fix harder ones. Firebird is not the only pb, charts aren't displayed anymore in reports and the whole reports part is dependent on old Java external components. There are also address books pbs: - Mac one (eg : leaks but not only this, Alex may tell more about this I suppose) - Thunderbird one can't be used anymore after Mork->Sqlite migration. I also think about Base stumbling on some specific functions added to standard SQL by some databases which can be workaround sometimes but not always. So yes, hiring 1 or 2 people on Base part could be relevant unless we'd like to abandon Base. Just to put it clearly here too, I'm not speaking for me since I already got a job and above all, wouldn't be able to do this job, I'm rather thinking about Lionel (if he agrees of course! :-)). I really think a strong decision (hiring people or abandon it) should be made instead of letting it rot. PS1: I'm adding Robert and Alex here since they're the main QA for Base part and may provide extra info. PS2: Lionel, don't hesitate to complete (or correct if I made some mistakes) what I said. On 25/03/2022 06:50, Michael Weghorn wrote: Hi Paolo, thanks for the updated draft and integrating my references to meta bugs. Another potential focus area might be Base (the database module). Alex mentioned it in another thread (that had a different main focus) [1] and I've heard from time to time that it isn't in the best shape. There's tdf#120062 [2] as a meta bug for database related bugs and enhancements. I'm not using Base myself, though, and don't have any overview of its current status. I've seen Julien doing some work there recently. Maybe he, Lionel or anybody else might be able to say more on whether it would make sense to consider that as a potential area to be worked on by TDF in-house developers. Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00060.html [2] https://bugs.documentfoundation.org/showdependencytree.cgi?id=120062_resolved=1 -- 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
Re: [board-discuss] Re: New draft of the proposal for in-house developers
On 25/03/2022 06.50, Michael Weghorn wrote: I've seen Julien doing some work there recently. Maybe he, Lionel or anybody else might be able to say more on whether it would make sense to consider that as a potential area to be worked on by TDF in-house developers. [Something went wrong when copy-pasting Lionel's email address to "CC" in the previous email, I've forwarded it to him in private.] -- 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
[board-discuss] Re: New draft of the proposal for in-house developers
Hi Paolo, thanks for the updated draft and integrating my references to meta bugs. Another potential focus area might be Base (the database module). Alex mentioned it in another thread (that had a different main focus) [1] and I've heard from time to time that it isn't in the best shape. There's tdf#120062 [2] as a meta bug for database related bugs and enhancements. I'm not using Base myself, though, and don't have any overview of its current status. I've seen Julien doing some work there recently. Maybe he, Lionel or anybody else might be able to say more on whether it would make sense to consider that as a potential area to be worked on by TDF in-house developers. Best regards, Michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00060.html [2] https://bugs.documentfoundation.org/showdependencytree.cgi?id=120062_resolved=1 -- 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
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
hi Andreas, On 14.03.22 18:36, Andreas Mantke wrote: and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). that's a bad example: the Android Viewer is in the core.git repository. there is no practical way to "move it to the attic" - in the hypothetical case, i'm pretty sure it would be considered too much effort to disentangle a dead project from core.git and there would just be a commit that deletes the code, as has happened for multiple large pieces of obsolete code in the past (just this year i happily deleted 2 WebDAV UCPs). -- 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
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Emiliano, On 08/03/2022 22:54, Emiliano Vavassori wrote: Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version. Proposal seems reasonable. This “attic” space will have, at minimum, the following characteristics: All sounds fine. ## De-atticization A part of the project that is actually present inside the “attic” can be moved back into active development, whenever sufficient interest around the code emerges. ## De-atticization requirements A repository can be deatticized when it reaches the following requirements: • A publicly available repository has to be present, collecting new modifications to the initial project. This repository needs to be based on the initial atticized repository; • The modified code has to be open source/free software under an OSI-approved license; • At least three different developers have committed changes to the forked repository, ideally not all of them affiliated to the same entity; • Every developer should have pushed 5-10 non-trivial commits over the span of at least three months; It would help to have another bullet here: * These active developers should all support its de-atticization. I think this was implicit, but lets make it explicit =) The following text is proposed to be included in the README of any atticized repository: Should be included in the README too I think. Otherwise, seems reasonable. ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] [DECISION] award text layout tender to Collabora
Hi Andreas,
On 10/03/2022 16:15, Andreas Mantke wrote:
Am 10.03.22 um 15:57 schrieb Florian Effenberger:
the 4 full board members participating in the vote were non-bidders.
In alphabetical order: Caolán, Emiliano, László and Paolo.
As for the 2021 budget, find the vote result at
https://listarchives.documentfoundation.org/www/board-discuss/2021/msg00091.html
>
are there comprehensible reasons why the voters on the budget items are
hidden in the wardrobe?
Is there a reason you're particularly concerned about this item and not
previous ones reported in the same way ?
> Once I read your answer I'm not fully convinced that the whole board
> is following the rules of compliance wholeheartedly.
Are you satisfied that your concerns were baseless ? Do you have a good
way to fairly judge people's hearts & minds ?
One thing that interests me is that the final sum is not included in
the public decision; that might be something to consider for the future
- I see no really good reason why it shouldn't be.
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Advisory Board Membership of Rubitech-Astra
On 26/02/2022 09:28, Thorsten Behrens wrote: The board has just decided to suspend the AB membership. Great work (and quick too). I do think we need to make it clear in whatever statement and/or notification we give that the individuals involved are not the problem, and that the door is open to return as/when they clarify their position and/or Russia ceases this horrifying aggression. I suggest someone edits the wikipedia page: https://en.wikipedia.org/wiki/RusBITech To remove our name. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.02.22 15:43, Paolo Vecchi wrote: Hi Michael, thanks for your feedback. On 25/02/2022 10:22, Michael Meeks wrote: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? The macro categories can be easily worked out but here they are: Commercial contributors: * Collabora * CIB->Allotropia Corporate contributors: * RedHat last i worked there, LibreOffice was a fully supported part of Red Hat Enterprise Linux that customers could and did file enhancement requests for. * Assigned (a bit of a mix but volumes don't change much the result) err, no: these are people who are not contributing as part of their employment, although they *may* be paid Google Summer of Code interns. the way it works is that or people who contribute at different times with different employers, their contributions for their employer are counted for their employer, while their contributions with no employer are counted as "Assigned". * NISZ * SIL * Munich Volunteers: * Unknown (no official affiliation) and TDF own contributions. > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > development and will help with the on-boarding of new external > commercial, corporate and volunteer contributors. Why do you believe that in-house developers (vs. say mentors) will help with on-boarding new contributors if that is not their focus? My suspicion is that mentoring is hard and "doing it yourself" is superficially easy in the short term. As from previous answer: "Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked." i think what Michael meant is: how do you get an experienced developer to spend 3 hours discussing a problem with a newbie spread across a longer time period and giving them hints to fix it and review their work, instead of simply fixing it themselves in a single session in half the time, if their job title is "developer" and not "mentor". > and the quantity of bugs, features and updates that may require > tendering or paid for services by the commercial contributors is > still so vast that it will not affect noticeably their income While it is true that there may be an inexhaustible amount of work and TDF will never reduce that by doing some of it, I'm not sure that is really relevant. Tendering has been used by TDF to help stimulate, diversify and sustain the commercial ecosystem around LibreOffice since the beginning. TDF has a fairly fixed amount of cash - if there is less of that to spend, that will have a non-trivial impact. The methods tested up to now to stimulate and diversify the number of more commercial contributors haven't brought the desired result as it seems like mostly 2 companies bid for those tenders so we'll have to work harder on it. how do you expect to grow the number of companies who bid for tenders if there are not more tenders? N companies bidding for a tender means that N companies spend significant time doing estimations, but N-1 companies get 0 income for that effort. Worse than that though is the possible for TDF to significantly harm the market for bug-fixing far in excess of any work it can do - by creating the idea that there is a "free" way to have issues addressed through political machination at TDF. I'm concerned by your comment as you seem to put in doubt the neutrality and the dedication to the wider community of TDF's team. Reading it in another way someone may even think that "political machination" tried to stop TDF to fully express its potential for serving the wider community. Naturally not many people came up with those thoughts so I guess they really aren't an area of concern for most. i guess you aren't familiar with the history of this project, but this was very common in OpenOffice.org times: when a beta was released, suddenly a bunch of people came out of the woodwork to complain very loudly on public lists why bug X or bug Y had not been fixed and how this could possibly be given that this bug is obviously so severe that the product is unusable. in many cases what happened then is that Sun fixed the bug before the release - a bug which was actually found by some enterprise user who deployed "free" OOo and paid a consultant to file the bug in IssueZilla and then make a noise about it, without paying any developer to actually fix the bug. -- To unsubscribe e-mail t
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
On 24/02/2022 15:56, Paolo Vecchi wrote:
On 24/02/2022 13:42, Michael Weghorn wrote:
Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to
separate that topic from the current discussion, which I think makes
sense.
I think it would make sense to focus on identifying non-controversial
areas that should be worked on (e.g. what's listed as "Focus areas"
from page 6 on) and then see how internal developers could help there,
but also leave room to discuss potential alternative solutions.
Agreed.
once they are settled and productive we should consider fulfilling our
mission for users
I think arguing that our mission requires us to do something or other
in app-stores is controversial, particularly for a fee:
The proposal draft says:
> As determined in the past months TDF has in-house competences that
> would allow us to start publishing LibreOffice Community in the
> Windows and Apple app stores at a nominal price.
Even if it is the right thing to do - and I think strategically it is
an important move to consider how the project gets income in this way I
would not say that:
The topic isn't that controversial as it has been discussed at length in
public and within the board.
discussing something at length normally is a good sign of it being
somewhat controversial =)
Last I heard there was still a significant push from some to make all
software free of price in every forum.
> Even if my preference is to have TDF running the app stores, so
> that we can reinvest not only in development but also in other
> projects that help the wider community,
I expect that all proposals here take into account the bigger picture
of delivering improvements for LibreOffice; the differences being mostly
over structure, control, jurisdiction etc.
> there are still 2 proposals for business entities that would do just
> that and the members of the ecosystem are perfectly fine with it.
So - I see no necessity to make the proposal more controversial than it
needs to be, by pre-deciding that TDF should employ resources to be
focused on this: which could be seen to prejudice this decision in line
with your preference. I would recommend removing that piece.
Anyhow - otherwise, as I've said - modulo some deep concerns over
decision making on how the new staff are deployed, and this unnecessary
angle, I'm mildly supportive (for what it is worth).
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] Re: Draft document for TDF in-house developers proposal
dressed through political machination at TDF. That needs extremely careful framing and communication to avoid drastically lengthening all consultancy horizons around LibreOffice: which are already lengthened by the "perhaps if we wait, someone else will fix it for us for free" problem. You seem to outline some ideas here but I'd like to see those substantially toughened - there needs to be clear, bright lines between TDF & ecosystem. Partly that is why I like focused mentoring. RTL/CTL and a11y seem like good areas to look at IMHO - I agree with the reasons outlined. Indeed - these are areas that have already appeared in ESC lists as I understand it. I agree that in-house staff can potentially make tender execution happen at-pace, which could be positive for complex things too in the bigger picture: though I suspect the execution issues around tendering are structural rather than necessary. > It should be added that in the tendering process related meta bugs > don’t seem to be considered as part of the tenders as the > ramifications represented by interlocking bugs could be seen as very > difficult to evaluate and to quote. There is some degree of seeing in-house developers as a panacea here: cheap, effective, can handle all complexity immediately, are trivial to manage & motivate (I didn't see any technical leadership or management provision) etc. LibreOffice presents some spectacular engineering challenges - and if a problem is complex and risky to tender it is certainly going to be complex and risky to deliver - and/or may easily take a nearly unbounded time, or even fail completely. > As determined in the past months TDF has in-house competences that > would allow us to start publishing LibreOffice Community in the > Windows and Apple app stores at a nominal price. This is controversial. It doesn't belong in this proposal but will expand on that in a separate mail. ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Paolo, thanks for your reply and additional explanations! On 24/02/2022 16.56, Paolo Vecchi wrote: Yes the initial plan is to look at the general areas and then the team will work out with the developers which bugs they can start tackling on their own, with mentoring and/or with experts support. That sounds reasonable. FWIW, for a11y, a blind user with whom I got into contact via LO's a11y mailing list has also made a personal ranking of issues related to using LO with the NVDA screen reader on Windows that he'll most probably be happy to share with anybody who's interested. Are those issues that could be filed as bugs? The interest is surely there, let me check the best way to have it posted somewhere so that it will be evaluated for internal development and/or tendering. The ranking was actually for bugs that are already in either LO Bugzilla or NVDA's Github issue tracker. For the LO Bugzilla, this was a subset of the bugs *directly or indirectly* blocking the general a11y meta bug tdf#101912 that I mentioned in my previous email. [1] More exactly, it were the tickets set as *directly* blocking for the Windows-specific a11y meta bug tdf#60251, the general a11y meta bug tdf#101912 or the sidebar a11y meta bug tdf#103440; Bugzilla query: [2] (Note how the first link contains direct and indirect dependencies, while the second doesn't, so the second is a subset of the first one.) For NVDA's issue tracker, it were those bugs that have a LibreOffice/OpenOffice-related tag/label. Many issues have been reported in both issue trackers and the table maps those to each other. My own focus for having developers would be less to "compensate eventual other drops in contributions" (p. 4), since I think the goal there should rather be to ensure an environment where others, including ecosystem companies, are happy to start/continue contributing (more) - which is also explicitly listed as a goal. The focus is surely to increase the number of contributors and to help ecosystem companies in being successful with business models that bring benefits to them, TDF, LibreOffice and the wider community. In the document you'll notice that I also wrote "clearly indicates that we need to work to foster new contributors with the help of new in-house developers and mentors." Yes, that's what my "which is also explicitly listed as a goal" was referring to (but which maybe wasn't really clear in my email), and I think that's definitely an important aspect. And from what I understood, this also seemed to be uncontroversial in the BoD meeting about the topic. The in-house developers are actually part of the strategy to help current and new contributors. Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked. That sounds very good to me. Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense. I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions. The first part of the document presents the general strategy and the app stores are part of it. Surely we should start with creating an initial team that starts working on the "Focus Areas" but once they are settled and productive we should consider fulfilling our mission for users that are locked into app stores or just find it more convenient to used them instead of downloading LibreOffice Community from our site. The topic isn't that controversial as it has been discussed at length in public and within the board. Even if my preference is to have TDF running the app stores, so that we can reinvest not only in development but also in other projects that help the wider community, there are still 2 proposals for business entities that would do just that and the members of the ecosystem are perfectly fine with it. Thanks for the explanation. My main concern was that "trying to do too many things at the same time" would potentially make finding a consensus harder. Regarding interoperability with MSO (p. 6), I don't have the impression that this is in general a neglected topic that would necessarily need special attention from TDF side at this point (in addition to what's already happening e.g. via tenders). The link that you provided for the metabug seems to show that there are a couple of bugs or three that need some attention. Certainly! There is certainly enough work to engage a multitude of developers in this area (and others). My thought was that - other than other topics mentioned - it generally seems to be less of
[board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Paolo, thanks a lot. I haven't added an extensive list of bugs or improvements in the main document as I think we should, with your feedback and with TDF's team, create a set of addendum for each area. Regardless of the progress of this proposal I will ask the board to involve TDF's team to formalise a selection of issues/bugs that need attention in the listed areas so that, depending on the level of readiness of the developers, they can straight away start working on them. I naturally ask all of you to help the team by sharing your point of view in this thread. By "formalise a selection of issues/bugs", do you mean to to create a list of specific tickets that should be worked on in the mentioned areas? If so, I'm wondering whether that's already needed at this point of the process of trying to find a consensus on the general direction. I'd expect that creating a proper, ranked list of issues would be a large task by itself, and with the "TDF developer should be(come) the topic expert" approach, I'm wondering whether it wouldn't be enough to identify potential areas to be worked on for now. For the areas mentioned in your proposal, existing meta bugs/Bugzilla keywords might be a good starting point: * RTL/CTL: meta bug tdf#43808 [1] * CJK: meta bug tdf#83066 [2] * a11y: meta bug tdf#101912 [3], and "accessibility" keyword [4] * MSO interop: meta bug tdf#107585 [5] * regressions: "regression" keyword [6] FWIW, for a11y, a blind user with whom I got into contact via LO's a11y mailing list has also made a personal ranking of issues related to using LO with the NVDA screen reader on Windows that he'll most probably be happy to share with anybody who's interested. Please do let me know what you think of the draft proposal and how it could be improved. I'm not familiar with what such kind of document for BoD discussions/decisions should look like in general and I don't want to go too much into detail about specific passages; just a few personal thoughts: I think the proposal has many good points. I'm not sure whether it already addresses all the concerns others have brought up earlier, but others can certainly speak for themselves best. In any case, I think it would be essential to continue discussing in a constructive way and try to find a consensus together, and having having this document as a basis for discussion now seems very helpful. My own focus for having developers would be less to "compensate eventual other drops in contributions" (p. 4), since I think the goal there should rather be to ensure an environment where others, including ecosystem companies, are happy to start/continue contributing (more) - which is also explicitly listed as a goal. Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense. I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions. Regarding interoperability with MSO (p. 6), I don't have the impression that this is in general a neglected topic that would necessarily need special attention from TDF side at this point (in addition to what's already happening e.g. via tenders). The "Knowledge Sharing" section (p. 5) has this: The additional positive side of creating a team of in-house developers is that TDF will be able to accumulate and share knowledge and become the neutral forum where all contributors can exchange information and learn how to contribute better and more to LibreOffice. It's not clear to me what exactly is meant by this. I don't see any general need to find a different/additional "forum" to exchange information in addition to what developers already have right now, at least nothing that would directly be related to the question whether or not TDF hires internal developers. (IMHO, TDF developers should in general just participate by the same means that other developers do, though of course they might have a stronger focus on supporting others in learning how to contribute better.) Best regards, Michael [1] https://bugs.documentfoundation.org/showdependencytree.cgi?id=43808_resolved=1 [2] https://bugs.documentfoundation.org/showdependencytree.cgi?id=83066_resolved=1 [3] https://bugs.documentfoundation.org/showdependencytree.cgi?id=101912_resolved=1 [4] https://bugs.documentfoundation.org/buglist.cgi?f1=keywords_id=1423830=substring_format=advanced=---=accessibility [5] https://bugs.documentfoundation.org/showdependencytree.cgi?id=107585_resolved=1 [6] https://bugs.documentfoundation.org/buglist.cgi?f1=keywords=0_id=1423829=substring=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id_form
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Simon, thanks for all your considerations regarding accessibility. On 10/02/2022 23.25, Simon Phipps wrote: The challenges are often attached to systemic issues and need extended time of LibreOffice experts to unpick the root cause before implementing the fix - even specifying them to tender takes research and pre-work as I expect you know. We've tendered these sorts of issues, and we could consider employing someone to deal with them full time, yes. However, there are also specialist elements - having accessibility devices for testing, for example. My sense is we would be better off paying an existing expert team (there are a few companies who specialise, not necessarily "the usual suspects") to take on the whole backlog for us for maybe 18 months, doing both engineering management and implementation and joining the ESC while they do. After that I'd return to the topic and reconsider the best approach in the light of that experience. I can see pros and cons for both approaches (internal developer, tender). In case of tendering, I think some cooperation of a11y experts and LO experts (like a company specializing on a11y + "one of the usual suspects") might even be more ideal than just an a11y-specialized company by itself, since from what I've seen so far, I suspect that some of the issues are somewhere deep down in the Writer/Calc/... stack that might take people without any previous experience with LibreOffice development quite a while to get into. In any case, I think it would be important to also make sure that there will be a possibility to get a11y issues fixed in the future as well. In case of a TDF developer, that should be relatively straight-forward because the developer can "just work on it". In case of tendering, I would see a need for some kind of arrangement that will allow to hand out follow-up tasks without having to go via the usual tendering process, which would otherwise allow an issue that is identified today to be considered only in a proposal for next year's tendering budget, so there would be quite a delay. (I don't know whether that's possible, but maybe, some longer-running contract to be able to hand out additional smaller work items flexibly as needed might be a solution, once the initial work has been finished.) Best regards, Michael -- 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
Re: [board-discuss] Separating users/community/contribution? (was: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs)
Hi Thorsten, On 11/02/2022 03.04, Thorsten Behrens wrote: Michael Weghorn wrote: and I remember that the importance of users was emphasized at some in-person event I attended (probably Akademy) as well. And I would agree. A user-facing project (opensource or not) that doesn't care about users in the aggregate is probably doing something wrong. I completely agree here and that was also one motivation of writing my previous email. This is not directed to you at all, but I sometimes have the impression of hearing some notion of "Why should we care about the users that don't contribute anyway?" in some discussions, which I personally don't like. At least for myself, improving LibreOffice for our users (including those that don't contribute at all) is a crucial aspect in my personal motivation to contribute to the project. Just to mention it, the KDE Code of Conduct contains this: Our community is made up of several groups of individuals and organizations which can roughly be divided into two groups: * Contributors, or those who add value to the project through improving KDE software and its services * Users, or those who add value to the project through their support as consumers of KDE software I'm not sure KDE would have a fundamentally different view here, but happy to have that conversation & perhaps hear new, fresh perspectives. The quote was mainly in response to the question of whether or not (non-contributing) users should be regarded as part of the community. In case there was interest in getting some fresh perspectives, I'm wondering maybe talking about that in some Advisory Board meeting might make sense, given that e.g. GNOME and KDE are members there. To clarify what I mean (and why I think KDE's take is not so different), the KDE manifesto [1] has this: * End-User Focus to ensure our work is useful to all people I'm perfectly in-line with that mission statement, as a guiding principle. But I would not turn down a contribution because it doesn't meet that standard yet (and instead try mentoring and other ways to improve it over time). I would, though, dismiss user requests that don't meet community norms, and not bother mentoring everyone until they understand. Thanks for the explanation, that sounds completely reasonable to me (at least as long as the contribution isn't known to badly break things for a certain group that worked previously). For perspective: it is not a scalable task to care for 200 million users individually. It is though a priority for me (and I hope achievable), to care for all our contributors, individually. Thus, mentoring existing, and attracting new contributors will always have a higher priority to me, than fixing end-user bugs (with project resources). Of course, there's nuance. The areas you and others have mentioned, that would need special attention, are worth tackling. I totally agree that's generally a reasonable approach and looking at it on a case-by-case basis as needed makes sense. Best regards, Michael -- 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
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Kendy, thanks for sharing your thoughts/concerns! On 10/02/2022 22.46, Jan Holesovsky wrote: I have expressed elsewhere in this thread that I am a proponent of hiring more development mentors rather than generic developers; so it is hard for me to get excited about this proposal. Also I forgot to answer Heiko elsewhere that his idea of graphics designer / website developer in one person sounds reasonably positive to me. I believe that not being excited about the idea is totally valid. Let me explicitly mention that I'm also open to other suggestions and how they would help to move forward with the issues that were brought up. As mentioned in my reply to Michael [1] however, I'm currently not so convinced whether "plain" development mentors would have the same chance of providing success when it comes to progress in *specific* areas (which does not at all mean I'm against having more mentors in general). Having said that, maybe we can get a bit more constructive even in this discussion about hypothetical possibility of hiring generic developers; so what about this: Michael, please - would you be willing to further your (and Sophie's) idea in form of a document that can be discussed as a whole, particularly how the details together fit the TDF mission? While I wouldn't say I came up with the general idea, I'm happy to contribute my thoughts in case the decision in today's BoD meeting is that it's worth having such a document for further discussion. I don't think I'll be able to do that just by myself (and there are certainly people who know better "how TDF works"), but I'm definitely willing to be part of a group that creates such a document. I'll reply with some first thoughts to your questions below for further discussion without claiming those are "the ultimate answers". In any case, I'm happy to learn and hear other opinions. I myself would be interested in the following questions; do you think you can cover them some way, please? * How to frame the hiring process - where developers should have a say in it, without being accused of CoI? I'm not familiar with the TDF hiring process. Is it so that the BoD is involved here and ultimately takes the decision? If so, I don't see any lack of competent developers in the new BoD to cover that perspective. :-) In my previous email I wrote that I personally wouldn't assume a CoI in case the tasks of TDF developers were set accordingly, and it definitely sounds reasonably to me for all BoD members to have a say. I'm not too familiar with the CoI policy, but as I understand it, the remaining BoD decides whether or not a CoI exists for a specific member. So would that point be addressed in case all BoD members agreed that all BoD members can have a say in the vote? (Whether or not all BoD members agree here is obviously a question I cannot answer.) * How to make it quick, so that the potential hires are still available once TDF decides for this or that candidate? I'm not familiar with the TDF hiring process, but I would assume the answer here should be unspecific to the specific role of the person being hired and would arise just the same in case of hiring more development mentors instead. * How to get the developers up-to-speed or mentor them once they are hired? That probably depends on whether the hired developers are completely new to the project or have participated previously. In general, I'd go with the established approach that is used for non-TDF contributors as well (have them learn by doing). * Also how to task them, how to day-to-day manage them, [...] (splitting this here, second part of the sentence below) That's up to discussion, my initial idea outlined in my previous email [2] would be to involve ESC and/or BoD when it comes to larger topics to be worked on. I personally wouldn't see a need to control every single small item that they work on but give them some "freedom" to work on what they identify along the way as they work on larger topics. But if there's a concern that would be problematic, more micro-management from BoD (or some representative that has been assigned by the BoD to take care) would of course be possible as well (like assigning specific Bugzilla tickets to work on or first discuss the thoughts they come up while doing their other work). [...] and how to make sure they are progressing at a reasonable pace? * What to do if they get stuck, and there is nobody in the community who can help them? I think those are questions that every developer is facing. My personal perception is that developers are working together well and there has so far basically always been help from others when somebody asks for specific help at a certain point (via developer mailing list or IRC). * How to detect they are not performing, and just consume the donors' money?z As above for the hiring process: I t
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Michael, all, On 10/02/2022 17.53, Michael Meeks wrote: There is a huge amount of need around LibreOffice development. It is easy to find a hundred different "top priority" issues each dear to the heart of a user, each user convinced that if only we had eg. 'Reveal Codes' in writer everyone would use LibreOffice. True, and I think there is consensus that not everybody's personal "top priority" issue can be handled, no matter what steps are taken in the end. As for no-one listening to users - I spend my life listening to customers & partners & users - and trying to do what they want. Anyone jealous of some big pool of unconstrained money / development power in corporate contributors is mistaken. Nevertheless I still get impassioned complaints of why Collabora did X and not Y from intelligent, articulate, engaged community members. To mention it explicitly: Thanks for all that you and Collabora are doing for LibreOffice, that's much appreciated and I think nobody here is expecting Collabora to solve all problems by itself. TDF in contrast while it has many constraints on what it can do - has few time constraints on its spending, which frees it to do more strategic long-term work. Thus it can invest more efficiently with some multiplying factor - via the educational / mentoring role into specific areas. I for one would support some targeted a11y / CTL mentoring - those seem like good areas that Sophie outlines - and ones where we can perhaps shine & grow the contributor community. However - there is a cliff-face of need here. It seems totally sensible to suggest that hiring internal developers without any plan of working out what they should work on seems premature. Part of why mentors are attractive is that their agenda is partly lead by what volunteers want to do. That can be steered of course by creating new easy-hacks / tasks / projects in directions they want to go - and/or learning on the job themselves by hacking on things. I completely agree that TDF has different constraints than other contributors and that could allow, among others, for doing more strategic work, rather than only focusing on single bugs that are important to specific users. I'm not so sure, though, whether mentoring alone will be enough to ensure that otherwise neglected areas will sufficiently be taken care of. For that to work, there at least need to be capable people willing to be mentored and to work on those topics, and having a certain amount of time to do so. I'm skeptical whether having more mentors alone will necessarily also provide for that. I am wondering whether dropping a strict distinction between the two roles (developer, mentor) might help here. My expectation would be that a TDF developer currently "responsible" for a certain area would also be a great mentor in case people willing to work on that show up. And once other contributors are willing to take care of specific areas, I believe it makes sense to allow them to work on that and have TDF staff focus on something else. I think some flexibility depending on how things develop would nicely be able to deal with both scenarios: the one where other contributors interested in a specific topic show up, as well as the one where they don't. For myself, I would want to see some sensible mechanism that includes the views of those who contribute via donations as to what is important. Then again if we dedicate donations solely in-line with what donors want - I suspect certain key functions: admin, marketing might not get the attention they deserve: so again, there is no obvious solution here beyond the board getting wide input and deciding (as they do now). While I understand that details need to be sorted out on how to prioritize potential development topics to be worked on, I believe it should be doable to find a way. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. These days the we have created rules to exclude people from such decision making - which has the potential to significantly exacerbate conflict and division I feel. But you're right, in theory the BoD is sovereign. In my previous email, I wrote: "Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all." I admit that this will probably be very hard if members of the involved LibreOffice/TDF bodies don't find a way to work together constructively, but rather "fight against each other". But I think that's a problem on a completely different level, and I don't see how TDF can properly serve it's purpose then anyway, regardless of the specific question around TDF-internal developers being discussed here... Bes
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Thorsten, all, On 10/02/2022 18.07, Thorsten Behrens wrote: It is putting the cart in front of the horse though, to start with: * we want TDF to contribute more code to LibreOffice and then follow with * therefore we must employ two developers Whether or not that's an adequate summary of Paolo's proposal is not up to me to judge, but... I believe it is more productive to start thinking about what we want to achieve, in order to fulfill our mission. It is therefore encouraging to read some good thoughts about that (RTL/CTL, a11y, and other under-developed areas with little ecosystem contributions). The board can then ponder what is the best way to achieve those goals, relative to other demands. It is possible, but by no means certain, that actually hiring specialised staff is indeed the most economic way forward (e.g. for an area like a11y). ... I completely agree that having a clear goal and considering the pros and cons of different approaches to get there before taking a decision definitely makes sense. Best regards, Michael -- 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
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Daniel, On 10/02/2022 14:53, Daniel A. Rodriguez wrote: El 10/2/22 a las 08:30, Stephan Ficht escribió: So, everyone and everything being an important piece in the mosaic for the big picture for a FLOSS office suite, called LibreOffice. Crystal clear, for some of us at least This reminds me of a comment by MMeeks where he made reference to the fact that those who do not code have no say. Which is a total absurdity. That has slipped my memory. Perhaps you could share a reference to this comment and its context to substantiate your summary. And it's rather unfair asking you this - when I get a blizzard of this sort of misrepresentation left & right from others, but I have come to expect better of you Daniel =) Thanks ! Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Thorsten, On 10/02/2022 17.55, Thorsten Behrens wrote: Sole users (i.e. without contributing anything to the community) are to my mind never part of a FLOSS project community. Just to mention it, the KDE Code of Conduct [1] contains this: Our community is made up of several groups of individuals and organizations which can roughly be divided into two groups: * Contributors, or those who add value to the project through improving KDE software and its services * Users, or those who add value to the project through their support as consumers of KDE software and I remember that the importance of users was emphasized at some in-person event I attended (probably Akademy) as well. Of course, one could try to make a distinction between users that contribute something back and those who do not, but I don't know whether that would be particularly helpful, or even easy. (E.g. is a user that only uses the software for themselves not part of the community, but one who recommends it to others is, because they "spread the word"? - And maybe one of those starts getting active in some "official" area in the LibreOffice project, or migrates their company from a proprietary office suite to an LTS version from an ecosystem company,...) Best regards, Michael [1] https://kde.org/code-of-conduct/ -- 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
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, thanks for your reply. On 10/02/2022 16.31, Italo Vignoli wrote: On 2/10/22 13:36, Michael Weghorn wrote: Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. Totally agree. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering. I totally agree, extending that process to cover significant tasks that internal developers would work on may be a solution. Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions). To double-check nobody is "secretly" working on that as well or is planning to do so, discussing/mentioning larger items first certainly won't hurt. (But that doesn't only apply for work done by TDF developers; e.g. the weekly ESC call already has a "What’s cooking" section where that would fit well.) I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone. Definitely! Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...] At least from my developer's perspective, I totally agree with what you wrote. Best regards, Michael -- 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
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Italo, On 10/02/2022 15:31, Italo Vignoli wrote: On 2/10/22 13:36, Michael Weghorn wrote: I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be. Yes, but it looks like the discussion is blocked one step before reaching a consensus on this very simple point. It seems reasonable to explore what people should be hired to do - before hiring them =) That has the benefit of working out what skills are needed in the job advert and/or interview process for example. The 'discussion' here - I would not see as blocked, but problematic see later. There is a huge amount of need around LibreOffice development. It is easy to find a hundred different "top priority" issues each dear to the heart of a user, each user convinced that if only we had eg. 'Reveal Codes' in writer everyone would use LibreOffice. As for no-one listening to users - I spend my life listening to customers & partners & users - and trying to do what they want. Anyone jealous of some big pool of unconstrained money / development power in corporate contributors is mistaken. Nevertheless I still get impassioned complaints of why Collabora did X and not Y from intelligent, articulate, engaged community members. TDF in contrast while it has many constraints on what it can do - has few time constraints on its spending, which frees it to do more strategic long-term work. Thus it can invest more efficiently with some multiplying factor - via the educational / mentoring role into specific areas. I for one would support some targeted a11y / CTL mentoring - those seem like good areas that Sophie outlines - and ones where we can perhaps shine & grow the contributor community. However - there is a cliff-face of need here. It seems totally sensible to suggest that hiring internal developers without any plan of working out what they should work on seems premature. Part of why mentors are attractive is that their agenda is partly lead by what volunteers want to do. That can be steered of course by creating new easy-hacks / tasks / projects in directions they want to go - and/or learning on the job themselves by hacking on things. For myself, I would want to see some sensible mechanism that includes the views of those who contribute via donations as to what is important. Then again if we dedicate donations solely in-line with what donors want - I suspect certain key functions: admin, marketing might not get the attention they deserve: so again, there is no obvious solution here beyond the board getting wide input and deciding (as they do now). If the discussion stays as such, I have to say that I don't feel I am represented - as a TDF Member - by any member of the just elected board of directors (of course, those who have expressed their opinions). and: > Of course, given my complete lack of understanding of development, is > too easy to find a technical angle to disprove what I just wrote, but > it would also be disproving what many of the contributors - the > community - think, and this would confirm my personal belief that > TDF BoD does not represent the community as a whole, but only a > portion of it. It would be deeply unfortunate if the above was read as questioning the legitimacy and composition of the new board - and that before they have been seated and/or taken a single decision. It would be good to clarify that reading. I would note that everyone who stood for the board was elected - and perhaps acknowledging the complexity of what might look like simple decisions from the outside - is real & not imaginary. I wish them the best as they try to find the local maxima in some multi-dimensional problem space. As for finding new board members on the list to express a view you feel represents you: these long threads packed with trolling and misrepresentation on board-discuss are not a great way to interact I suspect. Why would a new board member want to engage in them while they find their feet ? Lets not be quick to preemptively despair of sensible decision making. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. These days the we have created rules to exclude people from such decision making - which has the potential to significantly exacerbate conflict and division I feel. But you're right, in theory the BoD is sovereign. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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.
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi all, On 08/02/2022 17.01, sophi wrote: Le 07/02/2022 à 19:16, Paolo Vecchi a écrit : * Members of the ecosystem and others also suggested that we should spend more money in development * Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem * We need to build up internal skills and development capabilities to speed up innovation I agree here that there are several areas like CJK and CTL (and not only for bug fixes) or ally that should deserve much more love from TDF and I'm sure our donors would be happy that we invest in this area too. That would help also to grow this part of the community, which is very complicated to achieve when our version is difficult to use. That sounds like a good approach to me, in particular for areas where there's currently no specific interest from ecosystem companies or volunteers and that are unsuitable for tenders, but considered important for the community. I would see that in line with how TDF already employs non-developer staff to take care of other important aspects not (sufficiently) covered by other contributors. I have the impression that a fundamentally important question is what the purpose/task of TDF-internal developers would be. If larger topics that TDF-internal developers were to work on were first agreed on in the bodies where ecosystem companies are present as well (like ESC and/or the board), my expectation would be that the development work from different sides should work together nicely, rather than creating any kind of destructive competition. (Ecosystem company products profit from contributions made to LibreOffice as well, and having a better overall product should in my opinion also increase the range of potentially interested customers in general.) Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies. Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all. However, I must admit I don't know the ecosystem company perspective first-hand, so would be interested in learning more about specific concerns. Best regards, Michael -- 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
Re: [board-discuss] Drafting Tender "Cleanup & further improve ODF conformance"
hello again, On 03.02.22 14:30, Florian Effenberger wrote: Florian Effenberger wrote on 01.12.21 at 15:30: (3) Is it possible to get https://bugs.documentfoundation.org/show_bug.cgi?id=48392 ODF: Implementation for svg:linearGradient and svg:radialGradient is missing as explicit issue for "Required"? We had this already as suggestion "Multi-color gradient" in https://wiki.documentfoundation.org/Development/Budget2021 and now again in https://wiki.documentfoundation.org/Development/Budget2022 I've added it. Not sure, however, how much that would change the work/cost estimate of the tender. This is in the draft. We can add a similar note as mentioned above if we're unsure about the work required. so i've discussed this with Armin now and we noticed that this would be a *lot* of effort and really should be a separate tender, and the gradients are currently listed separately in the Wiki page. or, put another way, if you put the gradients into this tender there won't be any time to fix any other bug. regards, michael -- 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
Re: [board-discuss] Drafting Tender "Cleanup & further improve ODF conformance"
hi Florian, On 03.02.22 14:30, Florian Effenberger wrote: Hello everyone, the below mail is a bit older - Christmas break and some other tenders came in between, so I get to this only now. Florian Effenberger wrote on 01.12.21 at 15:30: (2) The search result from item "Required 2." contains Meta-issues. Expanding them results in 80 issues. Using Whiteboard as search criteria has no advantage compared to the Meta-issues. And I think both, Whitheboard search or Meta-issues, are not suitable for a tender, but a tender needs to list the issues explicitly. The list from Whiteboard search and Meta-issues needs to be examined and prioritized manually. This is taken from the specification at https://wiki.documentfoundation.org/Development/Budget2021#Cleanup_.26_further_improve_ODF_conformance I fear answering that question is beyond my skills. ;-) Does it make sense to bounce this question back to the ESC for further specification? Regina (thanks a lot!) sent a list of bugs back in December on the dev mailing list: https://lists.freedesktop.org/archives/libreoffice/2021-December/088210.html Was there any further discussion or feedback on this? If the list mentioned there is fine, I replace item 2 from the tender with it. If we're unsure whether that meets the budget or not, as the person days are listed in the tender, we can add a note along the lines of "Please propose a subset and prioritization of these bugs, that do not exceed the person days factored in for this tender, see below." thanks for reminding me, due to too much vacation i forgot but now i just provided some feedback about some of the issues to Regina. i haven't thought about how much time the selected issues would require yet, it's possible it might still be more than the budget which the BoD wants to spend, so i guess a fixed budget and then apply for a subset of the issues makes sense. Michael Stahl wrote on 03.11.21 at 10:49: the scope of this is quite large and unclear... *required* items are: 1. ODFAutoTests: addressing issues will be difficult because as Regina points out the web service appears to be offline. IIRC it's possible to run the tests offline, but currently i guess nobody knows how much work it is to set that up and what problems would actually be found, so i guess this item mostly amounts to "get ODFAutoTests to run at all". I've tried to rephrase #1 a bit, let me know if this is better. Is the current wording fine? i guess, as long as nobody interprets it to mean "set up a public website" :) -- 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
Re: [board-discuss] Looking forward, not backwards (was: Counterproposal to the "actization" of LibreOffice Online)
Hi Paolo, On 19/01/2022 14.38, Paolo Vecchi wrote: It could take a while to get new developers on-board but in the meantime do tell us when you are able to refine the proposal as it may then be picked up by ESC or a member of staff for further evaluation. thanks! My personal plan is to continue looking into a11y as I find time and I'm of good hope this will give me enough insights to come up with a refined proposal to be considered in the ESC voting for next year's tenders. Michael -- 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
Re: [board-discuss] Looking forward, not backwards (was: Counterproposal to the "actization" of LibreOffice Online)
Hi, On 14/01/2022 20.24, Paolo Vecchi wrote: Personally, I'm not interested in playing zero-sum games (taking development away from the ecosystem, and re-patriating it into TDF). Instead, we need to work much more on creating win-win setups, and supplementing each other. TDF must make its choices as corporate contributors have to make theirs. Fortunately corporate contributors have business models that allows them to grow without counting on TDF tenders so, while tenders will be still made to deal with complex development that other contributors are unable to tackle, we need to become capable of managing some of the project so that we are not always dependent on third parties that may not find a specific project fun or commercially interesting. That sounds like a good approach to me. There's definitely things that TDF can do much better than any ecosystem company. There's also definitely things that ecosystem companies are likely better suited for, than TDF. The same is true for our volunteer community True and that's why there is room for all to have fun and participate to make LibreOffice and related project great. +1 One obvious area where there's very little commercial incentive to do things is a11y. At the same time, that would be something very charitable to fund & further! If there's budget for funding internal development, a11y would be very high on my list of topics to focus on. That's something that has been on the list to do for a long time. I haven't noticed anything related to it in the ESC ranking or maybe it's simply not marked clearly enough. If it isn't there then we should ask the ESC to propose fixes in that regards? I think one point here is that doing a proper proposal for a tender requires having a rough understanding of the subject to be tendered, be able to define a reasonable scope and also give a rough estimation of how much work that will be. In other words, it either requires somebody who already has an overview and a good idea what to suggest, or somebody investing time to come up with something. Regarding a11y, as somebody who started looking into that topic, but without a clear idea on anything more specific for tendering, I had created this suggestion for tendering some (still to be selected) bugs from the a11y meta bug in Bugzilla: [1] I must admit that I wasn't too disappointed that the suggestion didn't make it into the top list in the ESC voting. Given that more time would have been required to further analyze bugs in question and select a reasonable subset for the tendering, I am not sure whether the overhead (on all involved sides) would much outweigh the effort, or whether it makes more sense for me to spend time in trying to improve a11y myself. I think tendering works best for items where the scope is clear beforehand, while here it would be much easier to say: "Here is a ranked list of a11y issues, spend X days on fixing as many as you can.", which to my knowledge doesn't really fit the tender model particularly well. Maybe others have better ideas on potential a11y topics to tender or there are better ways to handle this, that's just the story behind the above-mentioned proposal... (which is the one clearly related to a11y in the list of proposals that ESC was voting on, [2]). Best regards, Michael [1] https://wiki.documentfoundation.org/Development/Budget2022#Fix_accessibility_issues [2] https://wiki.documentfoundation.org/Development/Budget2022 -- 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
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Hi Simon, On 14/01/2022 18:14, Simon Phipps wrote: This has led to progress grinding to a halt through mistrust If TDF is to satisfy its mission this has to stop. The new Board has a huge opportunity and responsibility to put all this behind them and lead positively. It must shun divisiveness Thanks for your apt and helpful analysis & reflection on the way ahead. As a counter-point to some other perspectives: I am really grateful that you take the time to intervene positively in our community, to provide the benefit of your wide experience, as well as this sort of incisive and clear perspective that helps to cut through the clouds of confusion. I too hope the new board will be able to start afresh with new vigor on the task of making LibreOffice a welcoming and pleasant place to contribute for all. Thanks, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Commercial entity vs community development and distribution
On 13/01/2022 20:08, Ilmari Lauhakangas wrote:
On 13.1.2022 21.56, Michael Meeks wrote:
Oh - wow, I didn't know that. Wow - that is awful. That crushed
my hopes for a good Firebird based future.
Alex: seems the problem existed before Aug 2016, but not anymore.
...
'The problem was fixed by saving (within the odb zip structure) firebird
data in an endianess-independent format, called the "backup" format, in
a file with extension ".fbk".'
Phew - thanks for the update! Firebird/base is back on track as the
notional future =)
Good stuff,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Commercial entity vs community development and distribution
On 13/01/2022 12:35, Alexander Thurgood wrote: Thanks for jumping in on this thread, and I appreciate you having taken the time to address my points. Nice to talk the issues through constructively =) Oh, yes, I still remember the pain involved in transitioning from PPC to Intel. Quite =) Apple seems to deprecates APIs less quickly than Linux but rather more quickly than Windows. The downside for the commercial offerings then is why would I continue to keep subscribing to the AppStore versions (and contributing financially, however little that might be), if I have to have multiple different versions of what is perceived as the "same" software in order to get work done ? In a nutshell, if your primary focus is Base on Mac, then at the moment it makes little sense to - except of course that supports the project somewhat. Obviously you could support the project instead by donating to TDF. Lest there be some misunderstanding, I also wasn't touting that Base be atticised, far from it, that would be counter-productive for me Sure; I don't think anyone is proposing that. particular, my concerns were levelled more at the perceived (by me) risk that apathy, or lack of foresight at the Board level, or whichever circumstances, might lead to the commercially branded offerings of LO in the long run being the only ones available via the AppStore, or indeed anywhere. My take is that app-stores are a significant strategic risk to TDF from several perspectives and that keeping people's ability to install their own software alive - outside the grip of DRM'd app stores is an important thing to do. Also - the economics of endless free updates in app-stores hurts TDF's revenue very significantly when you model it: not de-funding TDF needs to be a concern for the project. Endian-ness for embedded Firebird seems to be the elephant in the room here. ODB files made on MacOS can not easily be shared with other OSes/arch. Oh - wow, I didn't know that. Wow - that is awful. That crushed my hopes for a good Firebird based future. So what other options are there for a sensibly licensed, in-process database ? Does PostgreSQL do it - could we run the server in a thread cross-platform, can we get its data into a file ? ;-) I guess we should prolly re-do the analysis of alternatives here to work out if there is a sensible way forward; but that belongs on the dev-list - and it's a big job to even know what we might want to do. You certainly highlight an interesting challenge. How can we find individual volunteers and resources to apply to such problems ? More development mentors may help, its worth a try - but I'm sure many more such problems will remain. Agreed, and I don't believe that there are any easy options, nor do I see any "prepackaged" solutions that will satisfy everyone. Yep; seems like a nightmare; the endianess issue burst my bubble of having a nice direction - but just getting there slowly. How can we avoid the galloping bit-rot and fund the improvement of a good database infrastructure ? it's an un-solved question. Thanks again for your input Michael, it is always useful for me to have this kind of engagement. No problem; Its a shame that the Linux Desktop is not floating your boat too, I agree with you on lots of what you wrote that I excised for brevity. Anyhow - I'd like to hope that we can research and come up with a plan for a capable database that we can bundle & be sure is always there for embedded db's; one that will not bit-rot, and is not built on another bit-rotting infrastructure =) I guess with Noel's experience perhaps a J2C++ conversion on HSQLDB would do it ;-) still at 100k LOC of Java that's also a nightmare. Hey ho, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
od things around the LibreOffice Technology and our desktop product. Perhaps I've not persuaded you, but I think the proposal while no doubt well-meaning is self-defeating for TDF, for LibreOffice, and for its contributing ecoystem. I also agree with Thorsten that the stories about achieving market dominance during the COVID crisis with this approach are impossibly naive. From a hardware provision perspective alone - being backed by a giant monopoly (which we are not), really helps to front the Eur 10's of millions of infrastructure cost needed to provide a large-scale free service. Also - I expect that selling users' private data or insights gleaned from it (something TDF would never do) also gives a significant cost edge against us. On the plus side - the tragic COVID crisis has encouraged a number of organizations to choose to move to LibreOffice Technology. Many have done that in a sustainable way - I hope their financial contribution and positive experiences of support will continue for many years improving LibreOffice to everyone's benefit. Hopefully that is something we can mutually celebrate, Regards, Michael. [1] - https://www.libreoffice.org/download/libreoffice-online/ eg. "why is this un-supported?" - this page forms the only substantial agreement I can see on the topic. [2] - https://people.gnome.org/~michael/data/vendor-neutral-marketing.html -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Commercial entity vs community development and distribution
and quite challenging to get right. I would hate to see the project further consumed by divisive in-fighting over what to do. I believe Marina came up with some way of getting users to direct the proposed TDC spending that sounded interesting and that could perhaps be used to encourage more financial contribution on focused issues - but TDC was unfortunately killed before it started, and that could be experimented with. So - anyhow - I hope those reflections help. You certainly highlight an interesting challenge. How can we find individual volunteers and resources to apply to such problems ? More development mentors may help, its worth a try - but I'm sure many more such problems will remain. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
On 09/01/2022 17:27, Lothar K. Becker wrote: Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures. In general, I think it is wise when (re-)starting an engineering project to get input from the engineering community who are represented in the ESC. Of course, the board is not obliged to do so, and it also appoints the ESC itself. If necessary it can stack it with yes-people. However, I would really suggest that making engineering decisions against the advice of the leaders of the teams that do the work is something that should give very serious pause for thought & consideration by a board. Or something like this. I am not sure if it is good to vote on it without clarification of this item in any case. What do you think? Clearly the board as the ultimately authority has many avenues to ensure its will is done: changing the policy, changing the ESC composition, etc. But as a general scheme of action for a peaceful and sensible approach to the problem, I think the policy as proposed is fine. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Draft text: an "attic" proposal
Hi Mike, On 06/01/2022 10.13, Mike Saunders wrote: Is there something we (from the side of TDF) can do about this, eg push a new release to the Play Store? If so, I can talk to Cloph (our release engineer) about getting an updated version out there... Thanks for asking. Whether it makes sense to push a new release to the Play Store is actually a good question, and I don't think I can answer that just by myself. So far, when looking at LibreOffice Viewer and potential alternatives, my personal assessment was that it was worth spending some effort to improve it to have a reasonably well working solution and I think it is useful in its current state. However, I don't really know whether it will make sense to keep it in the long run, in particular as alternatives (like the Collabora app) are further improved. So the question is probably: Does it make sense to start doing official releases again now when we don't know whether/for how long we'll continue to do so? I'm currently undecided on that myself, happy to hear other people's opinions... Best regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Draft text: an "attic" proposal
Hi Emiliano, thanks for the quick follow-up. :) On 05/01/2022 23.45, Emiliano Vavassori wrote: The absence of a release published in the Play Store (which is the main venue, to my perspective, to reach for users), its known limitations, the need of a reworking of the interface to get some interest back to the app and the appearance of a successful substitute app (the Collabora Office app you cited yourself) got me to the wrong conclusion, that it wouldn't be worked on and further supported, and no other interests were on my radar. Ah, I see and I would have agreed in case nothing had happened in the last years, since the app had actually been in a pretty much non-working state for a while. My first though about a general process to atticize core code is at least cumbersome and require much more work than leaving it there (and I can only understand high level development, as I am not a developer). What's your take? If something has been inactive for a while and it's not useful in its current state and there's no indication that this is going to change anytime soon (nobody is interested in working on it), I think it may be reasonable to just remove it (i.e. delete the corresponding source files). Since everything is in git, the removal can easily be reverted anytime should there be renewed interest. The "core" git repo itself remains active anyway, so patches could be submitted to Gerrit the usual way and there would be no need for any specific step to reactivate anything from the infra side (as opposed to how it is in the scenario where a separate repository is used). I think that would be in line with how we have been handling single features in the desktop version that were in a comparable state in the past - usually after discussing the removal in the ESC first. Best regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Draft text: an "attic" proposal
Hi Emiliano, all, On 05/01/2022 17.18, Emiliano Vavassori wrote: Il 20/12/21 20:34, Marco Marinello ha scritto: first of all, I'd like to state for those that are not into the current status quo that this proposal will mainly affect the "Online" project at TDF's infra. Not only. I can also name the Android "LibreOffice Viewer", for example. at least at this point in time, I (as somebody having contributed to LibreOffice Android Viewer during the last year) wouldn't see Android Viewer as a really good candidate for the attic. While it's not the most actively developed part of LO, it is (other than LOOL) still receiving contributions. And while there hasn't been any official release for a long time, daily builds are still provided by TDF [1] and the fact that users are occasionally reporting bugs in Bugzilla suggests that the app is being used by those. Can you possibly give a few more details on why you're considering it as another candidate for the attic? If there are any specific technical issues with the app (like critical bugs that make the app useless) I'd be happy to hear about those. (Maybe those can be addressed.) Of course, it's well possible that interest in LO Android Viewer may become even less in the future, in particular as the COOL-based Collabora Office app as a potential alternative becomes even more mature. But at least in the status quo, my personal opinion so far would be that it's not the time to put LO Android Viewer to the attic as of now. Best regards, Michael PS: As a side note, given that Android Viewer is contained in the "core" git repo, just like the desktop version, it would have to be clarified what "putting to the attic" would mean in detail for that specific case. [1] https://dev-builds.libreoffice.org/daily/master/current.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
Re: [board-discuss] Re: [VOTE] Approve version 1.3.1 of the CoI policy
On 23/11/2021 23:45, Thorsten Behrens wrote: calling for a VOTE on the just-published draft update to the CoI policy [1], to modify our Rules of Procedure [2] - such that we reference version 1.3.1 of the CoI policy: +1, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Proposed version of the CoI Policy 1.3.1
On 23/11/2021 06:51, Emiliano Vavassori wrote: We are all strongly committed to work on improved iterations, and so we already have a subsequent work-in-progress version 1.3.0, which I attach to this e-mail. It will be further enhanced with the contributions of all interested parties, to seek for an even broader consensus. There is a marginally improved 1.3.1 version here from review today: https://wiki.documentfoundation.org/images/1/1f/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.odt As per §1.2 of the Rules of Procedure, it is proposed to upgrade the relevant elements of the Rules of Procedure to replace the CoI policy with this somewhat ameliorated version of the same policy, after a board vote. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Drafting Tender "Cleanup & further improve ODF conformance"
On 29.10.21 08:32, Florian Effenberger wrote: Hello, one of the approved [1] tenders is the Tender "Cleanup & further improve ODF conformance" The board would like to work together in public with all of you on this tender before it gets officially published. The current draft is therefore shared at https://nextcloud.documentfoundation.org/s/ggqpciBK54rztJi The board is happy to get your feedback and proposals. We'd like to discuss this ideally in the board call after next, i.e. on Friday, November 19, at 1300 Berlin time. Please send your feedback to the public board-discuss@documentfoundation.org mailing list. the scope of this is quite large and unclear... *required* items are: 1. ODFAutoTests: addressing issues will be difficult because as Regina points out the web service appears to be offline. IIRC it's possible to run the tests offline, but currently i guess nobody knows how much work it is to set that up and what problems would actually be found, so i guess this item mostly amounts to "get ODFAutoTests to run at all". 2. odf_validation: * 37128 this is, errm, "interesting" problem and might take weeks to fix * 96066 likely needs specification work * 94768 cannot be solved with ODF 1.3, it needs specification work * 106934 needs specification work, possibly it was already added for ODF 1.4 * 131127 might be fixable? * 131148 needs specification work * 131159 this was added for ODF 1.4 * 108198 export meta-bug depending on 26 unfixed bugs, wow... * 94587 *import* meta-bug depending on 37 unfixed bugs - how does this have "odf_validation" keyword in the first place, i thought that applied only to the export filter? i would propose to remove "odf_validation" keyword and keep "odf". ... so i'm not sure what would make sense here, certainly *requiring* fixes of > 60 different bugs that are all over the map doesn't make sense to me, unless the board wants to spend the entire yearly budget... maybe everything should be "optional" and then applicants can list which bugs they think are actually possible to fix given the current ODF 1.3 specification? -- 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
[board-discuss] Updated representation statement Michael Meeks
I, Michael Meeks, elected member of the Board of Directors of The Document Foundation, hereby and until further notice, nominate the following deputy to represent me during board calls and meetings: 1. Nicolas Christener All the best, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Drafting Tender "Cleanup & further improve ODF conformance"
On 29.10.21 14:57, Regina Henschel wrote: Hi Florian, (1) The link http://autotests.opendocumentformat.org from item "Required 1." does not work. Do you have another reference for ODFAutoTests? the git repo is here: https://gitlab.com/odfplugfest/odfautotests but it does look quite inactive, with the last commit in 2015. possibly Jos van den Oever knows more... -- 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
Re: [board-discuss] Conflict of Interest Policy
On 08/10/2021 10:37, Emiliano Vavassori wrote: Il 06/10/21 14:46, Simon Phipps ha scritto: I will note none of the text has been supplied to or discussed by the legal committee (where I am a volunteer). I really appreciate your activity in the project and the Foundation. I will welcome very thankfully your involvement (and by extension, of any other volunteer) for the future versions of a CoI Policy. Just to re-iterate this: I personally find Simon's work on the legal committee invaluable. Simon regularly provides the benefit of his very considerable experience to the great benefit of TDF, in a most timely and helpful way in that context. I believe it would be extremely useful to include him into the timely review of this policy given his experience across many FLOSS projects. Thanks Simon, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Drafting "Tender to implement autoupdater"
Hello Florian, On 22/07/2021 14.18, Florian Effenberger wrote: Apologies if that caused confusion - from what I am aware, there have been no further discussions. Chances are it was a topic in the ESC, but at least from the tendering side of things, there are no news yet. Thanks for the clarification. :-) Michael -- 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
Re: [board-discuss] Drafting "Tender to implement autoupdater"
Hello, just a personal comment on this sentence in the draft: With plans of a “rolling release” model, that results in more frequent updates, e.g. biweekly or monthly, we want to improve this system. Just to mention it: The rolling release idea was - among others - discussed in an ESC call in December last year (minutes at [1]). The topic was controversial back then and if I remember correctly, the consensus was to discuss this again once there is a clearer perspective on how that might work in practice (which involves much more than the question of how an automatic update might work, s. e.g. some concerns in the ESC minutes). To me as a non-native English speaker, the above sentence sounds a bit like there were already more specific plans than what I can remember from back then and I cannot remember (but might have missed) a follow-up discussion on the topic so far. Anyway, I think that having a good auto-updater makes sense in any case, regardless of what decision will be taken regarding a potential rolling release model in the end (and therefore think the tender makes sense in any case). Michael [1] https://lists.freedesktop.org/archives/libreoffice/2020-December/086428.html On 21/07/2021 13.04, Florian Effenberger wrote: Hello, one of the approved [1] tenders is the Tender to implement autoupdater The board would like to work together in public with all of you on this tender before it gets officially published. The current, second iteration of the draft is therefore shared at https://nextcloud.documentfoundation.org/s/QP24tFdJio6MPxK The board is happy to get your feedback and proposals. We'd like to discuss this ideally in the next board call, i.e. on Friday, July 30, at 1300 Berlin time. Please send your feedback to the public board-discuss@documentfoundation.org mailing list. Those with a conflict of interest (i.e. potential bidders) will be excluded from the point on the tender is published and evaluated. Thanks a lot to Markus, Emiliano and several members of the ESC for working on the tender draft and helping us to write the second iteration of it! Looking forward to your feedback, Florian [1] https://listarchives.documentfoundation.org/www/board-discuss/2021/msg00091.html -- Florian Effenberger, Executive Director (Geschäftsführer) Tel: +49 30 5557992-50 | Mail: flo...@documentfoundation.org The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint -- 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
Re: [board-discuss] Vote about Certification Updates
On 06/07/2021 15:36, Italo Vignoli wrote: > As agreed during the last BoD call (July 2nd), I would like the BoD to > approve the following: > > 1. Develop a training for certification (attached), which allows to > access the "LibreOffice Certified" entry level (without specification > about migrations and training), after the usual certification review. > Once the training for certification has been approved, it will be > transformed into a series of online training classes provided through > Udemy (which seems to be almost a standard for certification training, > as it is used by Microsoft, Oracle and Cisco, plus others). > > 2. Keep the current "Migration Professional" and "Professional Trainer" > as main level certification for people who have a hands-on experience in > migrations or training (exactly as in the past). People with LibreOffice > Certification could apply for Professional Certification after 12 months > from the first certification, based on a migration/training project with > extensive documentation (a detailed report of the migration project, or > a detailed evaluation of the training project). Only people with full > pre-requisites compliance can directly access Professional Certification > without going through LibreOffice Certification. > > 3. Create the certification training for single applications: > "LibreOffice Writer/Calc/Impress/Draw/Base Certified Trainer", which is > simple and uncontroversial. > > 4. Create a "Senior Migration Professional" and a "Senior Professional > Trainer" certifications, only for certified professionals who have been > active in the project for a while and contribute as volunteers in some > area. > > 5. Update all certification related documents to reflect all the above. +1 thanks, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] Statement on Richard M. Stallman and Free Software Foundation
Hi Andreas,
On 25/03/2021 15:06, Andreas Mantke wrote:
> I'm missing some members of TDF bodies and the team here.
> Had they not reached in time or are there different views
> on the topic in general or only the wording?
I think I mentioned the difficulty and expense in time of getting a
consensus view quickly from a diverse set of people at the outset.
I'd would say this is a pretty good showing, and while I personally had
reservations about elements of this approach so didn't put my name to it
- it's certainly not safe to conclude that others who are not present
did not support it in part or total too.
ATB,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] TDF Budget 2021
On 25.03.21 09:52, Ilmari Lauhakangas wrote: On 25.3.2021 8.58, Ilmari Lauhakangas wrote: On 24.3.2021 20.46, Andreas Mantke wrote: Thus TDF has to evaluate the reasons for this poor execution and make improvements (especially for the time after the corona pandemic). If TDF will dodge on this topic, there will be from my opinion no valid reason to complain about a 'shortage' of volunteers in the LibreOffice project. I can't say I recognise your description as in 2021 alone I have onboarded over 130 volunteers and I'm not the only one doing this sort of thing. I have to correct myself: in 2021 I have onboarded 58 volunteers and in 2020 84 volunteers. Ilmari thanks Ilmari, i think it's great to have TDF staff onboarding volunteers :) -- 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
Re: [board-discuss] TDF Advisory Board Members
On 23/03/2021 18:56, Andreas Mantke wrote:
> Am 23.03.21 um 19:11 schrieb Italo Vignoli:
>> OSI statement: https://opensource.org/OSI_Response
>
> great and consequent statement.
Perhaps more measured than:
https://rms-open-letter.github.io/
Which is gathering steam, and focuses on the beliefs that are
acceptable in various communities.
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] TDF Advisory Board Members
Hi Andreas,
On 23/03/2021 10:07, Andreas Mantke wrote:
> What's the position of TDF board on this topic ?
As you know this sort of question is a very easy one to ask but as with
anything where there are a wide diversity of opinions - tends to be an
extraordinarily expensive one to answer in terms of board time.
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] donation infobar vs. straight donations ...
On 11/03/2021 16:28, Uwe Altmann wrote:
> One remark:
> Am 10.03.21 um 22:22 schrieb Michael Meeks:
>> * switch the donate URL in the app - to something that re-directs to
>> ... unfortunately that has no effect for~6 months ]
>
> Maybe we tweak not the URL in the app but that of the donation page
> instead? This would work immediately, not only in 6 month?
Great plan ! =) I think Christian is doing some data crunching for us
now, certainly easier to change the download web-page than the software.
ATB,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] donation infobar vs. straight donations ...
Hi Christian,
Is there any way we can differentiate the donation reminder infobar
from the download donation page ?
One of the things we really need to know is the cause of our increase
in donations; and I would love us to do two things:
* switch the donate URL in the app - to something
that re-directs to the same place, but is
distinguishable
+ Christian can we create an alias somehow
that we can easily log & update the source?
+ ideally we can track which source an actual
donation came through too.
+ Florian - does that need a redmine ticket ?
[ unfortunately that has no effect for
~6 months ]
* can we analyze donation page hits to look at
referrer over time, in particular who magically
arrived there (ie. any new ones are prolly from
the infobar). Is there a way to track the referrer
of an individual that actually donates ? why -
I'd bet we have a far higher conversion of infobar
users than people who just see that during download.
Would love to see the data; it's rather important to quantify to better
understand what to do with app-stores, eg. "in-app donations" vs.
download page donations.
Thoughts appreciated,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Agenda for TDF board meeting on Friday, March 12th at 1300 Berlin time (UTC+1)
On 10/03/2021 17:31, sophi wrote:> It's Videolabs who is the editor of
the apps, see:> https://www.videolan.org/videolan/partners.html>
Videolabs is the company run by Jean-Baptiste to support VideoLAN
Interesting. There are also some notable differences in the
functionality as described here:
https://www.microsoft.com/en-gb/p/vlc/9nblggh4vvnh?rtc=1
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] [VOTE] LibreOffice Online freeze-related decisions
On 02/02/2021 17:28, Michael Meeks wrote: > On 02/02/2021 17:10, Daniel Armando Rodriguez wrote: >> "rewind branches on https://git.libreoffice.org/online and for the time >> being deny all write >> operations to the repository, be it on the git or gerrit side. > > +1 Let me change that to a supportive abstention =) Thanks Daniel, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] [VOTE] LibreOffice Online freeze-related decisions
On 02/02/2021 17:10, Daniel Armando Rodriguez wrote:
> "rewind branches on https://git.libreoffice.org/online and for the time
> being deny all write
> operations to the repository, be it on the git or gerrit side.
+1
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] [VOTE] LibreOffice Online information in the release notes
Hi Florian, On 02/02/2021 12:15, Florian Effenberger wrote: > based on the previous discussion, putting the following to VOTE now: > > Ask the marketing team to summarize the new LibreOffice Online > information website (see vote item #1 in > https://listarchives.tdf.io/i/4bCUE2Lh2ffa-M8da8zEfPF7) in the release > notes, adding a link to the full page > > [Note: The content of that website is currently edited and discussed and > should be finished soon.] I'm really not a huge fan of the board voting in such detail on these specific sorts of actions. I'm rather confident in our marketing team doing what's sensible and incorporating feedback to move us in a reasonable direction perhaps based on high-level guidance from the board. Nevertheless the above seems un-controversial =) So +1 Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
Re: [board-discuss] [DISCUSS] LibreOffice Online freeze-related topics
On 13/01/2021 17:28, Simon Phipps wrote:
> On Wed, Jan 13, 2021 at 4:53 PM Daniel Armando Rodriguez
> Guilhem has a solid point here, if anyone leaves our project why should
> us go behind them?
>
> The people involved have not left our community or the LibreOffice
> project (yet). They continue to be our colleagues, friends and indeed
> contributors of all kinds, including upstreaming LO improvements that
> arise from COOL. Please be kind.
Thanks for that Simon =)
My understanding of Guilhem's usage stats is that OpenGrok is
essentially un-used (27k core vs. 535 online hits in the last 2 weeks).
I don't see any terribly compelling reason to keep OpenGrok open and
working vs. online if people object to that, COOL is significantly less
complicated than the LibreOffice core (which as I recall is the 98%+ of
the lines of code here).
OpenGrok seems an odd locus for a conflict; the costs are rather
trivial. The risk that it might (very slightly) help a group whose
financial, technical and general contribution to TDF and its mission is
quite real is there.
To soothe my Sayre's Law rash, I'd be well up for simply turning that
bit off if that's easier for syadmin.
ATB,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] [VOTE] LibreOffice 7.1 tag ("label")
On 07/12/2020 15:28, Lothar K. Becker wrote: > Find the SLIDES with the THREE PROPOSED TAGS at > https://nextcloud.documentfoundation.org/s/sTKeS4NipJ6X9XH > > which are from the discussion with our members, and also contain related > information on their strengths and weaknesses, provided by the marketing > team. > > The proposals, in ALPHABETICAL order, are as follows: > > a. Advance > b. Community > c. Rolling I rather liked Personal; shame really but: Community Rolling Advance would be my preference. Thanks to all for their input & deliberation. ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Re: [VOTE] LibreOffice 7.1 marketing plan
On 08/12/2020 08:18, Lothar K. Becker wrote:
> Find the SLIDES for this vote at
>
> https://nextcloud.documentfoundation.org/s/Z6Y2YeDKHoRW3s8
>
> which are a subset of the initially shared PDF, that was made available
> via Nextcloud. Removed from the aforementioned initially shared PDF are
> the following slides, that are irrelevant for the vote: slides 2, 10-14,
> 20-26, 36, 50-53, 62-64, 84
Having various Online pieces in this which have not been discussed in
the context of today makes this extremely difficult to vote for quickly
- particularly without a discuss thread.
The last board call we had:
+ re-look at the marketing plan (Paolo)
+ believe we should remove LOOL mentions for now
+ should be a live plan, we can modify it
+ for the moment: don't spend time
promoting LOOL until we have an alternative or
an agreement
That sounds very sensible to me; and:
+ see all slides - some should not be there (Lothar)
+ why I'm for this / that.
+ should have a version next week -
separate these out.
So I assumed these would be removed. If that is the case - then I
support the plan, +1, otherwise it will need significantly more thought.
Was that an oversight in shrinking the slides ? and of course, luckily
it's a link so easy to tweak ?
Thanks,
Michael.
--
Michael Meeks, <><, Director of The Document Foundation
Kurfürstendamm 188, 10707 Berlin, Germany
Rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: http://www.documentfoundation.org/imprint
--
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
Re: [board-discuss] [DECISION] LibreOffice Online - repository and translations
Hi Daniel,
On 02/12/2020 17:21, Daniel A. Rodriguez wrote:
> I consider that contributions to COOL, should not taken into
> consideration for TDF membership.
I'm sure the membership committee will take all of these things into
consideration as they deliberate. If that is their decision, perhaps it
is no bad thing to re-shape our membership over the next year.
It does however make it even more vital to get a mentor hired, unless
we want a rather smaller proportion of coders as members.
From the COOL perspective, our position is unchanged: We respect and
recognize the contribution of all the developers of LibreOffice and will
honor that in equivalent access: commit, translation etc. on our side.
Regards,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] [DISCUSS] LibreOffice Online - repository and translations
Hi all, I was interested to see this vote: On 26/11/2020 10:02, Florian Effenberger wrote: > The vote that has been proposed is the following: > > 1. to freeze (not delete) the "online" repository at TDF's git, for > the time being Of course, I'd prefer a clear decision to collaborate in a positive way with COOL and mutually celebrate each other. Absent that, it seems to me that Thorsten is rather sensible when he says: On 26/11/2020 15:53, Thorsten Behrens wrote: > I'm convinced it's the least-worst short-term measure, and leaves the > door open in all directions. Keeping that door open is useful; as I wrote in my original mail: https://www.mail-archive.com/board-discuss@documentfoundation.org/msg04727.html On 01/10/2020 10:13, Michael Meeks wrote (here): > Of course, we would love to see TDF coming up with the right mix of > structure, entities, stability, branding, appreciation of corporate > contributions and so on to build confidence that another approach is > possible. There is time before our next LibreOffice release in > January for the community to ponder what to do with LOOL, and to do > their own thing, or support this move to capture the benefits > outlined above. Collabora has so far kept the door open for a smooth reconciliation by (among other things) continuing to promote LibreOffice positively (which is easier when it is not necessary to differentiate against a LOOL) and by keeping COOL building against LibreOffice master. Simultaneously various positive, confidence building improvements to TDF's marketing have been planned. These seem to go in a generally helpful direction for the project; kudos to those involved. On the other hand it has been mentioned that first testing these changes in the Desktop version is necessary. Can we re-build the necessary company investment there? That, if successful, should demonstrate there is a stable, predictable environment with a sensible lead-flow coupled to contribution to drive new investment. It seems clear that this needs to happen before any changes to COOL. It will take some significant time probably many months. Time is also needed re-build the requisite confidence in the board upholding this wiser approach. It is also encouraging to see some of our historic concerns taken on board & creative steps discussed towards meeting some of them. On the other hand - a recognition of the many benefits that I outlined which can be easily captured without further changes would be good too. Against this, I was surprised to see some Board members' responses: Different board members wrote: > ... the LOOL subproject is key for the future of TDF and its community. and: > From TDF we must recognize the strategic importance of LOOL. That is > why the repository must remain active. That way, those who wish to > join and make the project shine, can do so. and: > "1) No. Let's work to implement better tools to make it easier > to people to contribute." The future of the LibreOffice codebase and those that love it is assured, even in the very unlikely case that Online is the sole future. The overwhelming majority of the code behind Online is LibreOffice. However the direction these votes appear to go in is one of pre-judging the result, encouraging divergence, and nurturing a competing LOOL project even while we test adapting LibreOffice marketing; and for what benefit ? I wonder if that is a wise, or even intended approach? The background is that in the last ~two months since the move there have been >700 commits to COOL, from a growing and diverse set of developers against two (2) (automated translation updates) to LOOL. Having votes by non-coders to keep open a sub-project that falls rapidly behind, currently with no contributors, and using the LibreOffice brand to keep it relevant is a curious choice. It also opens TDF and LibreOffice to potential negative comparisons & criticism. Far from being an un-mitigated positive for the project. Is that the intention ? it would be nice to have a clear statement ? as I wrote before: On 01/10/2020 10:13, Michael Meeks wrote (here): > Competing with people who take your code, represent themselves > as the creators of it, do nothing effective to mention us, and > compete with us in the marketplace is a problem. RedHat had problems > with Oracle Unbreakable Linux that were not dissimilar, where morally > they should be presented as the creators. This is where we came from, my hope is that it is not where we are going together. There are a few other things that are interesting questions: TDF needs to work out if it will be a pragmatic place where do-ers decide: we used to call that a meritocracy. I also hear the view that not having binary pr
Re: [board-discuss] Board of Directors Meeting 2020-10-23
Hi Quentin,
On 29/10/2020 00:00, Quentin Christensen wrote:
> I must admit I will have to go back and have a look at the current state
> of issues with LibreOffice 7 and NVDA 2020.3.
If you can come up with a list of prioritized / bucketed a11y issues -
we can try to estimate what it costs to fix them to get some work funded
here.
I was personally slightly sad to see though that the last tasks we
proposed here didn't make it through the ranking to get tendered. But
always worth trying again.
ATB,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
[board-discuss] Re: TDF-Business-Entity
Hi Andreas, On 30/09/2020 09:40, Andreas Mantke wrote: >> c) form sub-group to work out and publish business entity proposals >> URL: https://redmine.documentfoundation.org/issues/3294 >> Status: Criteria list (Lothar) Draft proposal for Luxemburg entity >> (Paolo), next meeting orga(Thorsten) ->> >> https://nextcloud.documentfoundation.org/s/NeBWm25cd2LHyoq ... > it's not a really appropriate behavior of a German charity to create a > business entity in a country, which is known as a legal tax shelter. I'm sure no-one would want us to search the world for a jurisdiction that is maximally burdensome to incorporate and run in =) For my part Luxembourg has the major benefit that Paolo wants to be involved and help get something done. It is hard to over-state how important it is to have not only a concrete proposal but good people on the ground. Incidentally this is why I was -so- dismayed to see the UK option discarded on what I felt were poor grounds. Either way - another advantage of Luxembourg is that we are blessed with having Lionel (CC'd) based there - at a professional accountancy that (if we're really nice) may kindly offer us the benefit of their accounting experience & help with oversight. That combination of long term understanding of FLOSS, LibreOffice as well as local company / tax issues would be an incredible plus. Beyond that - having a concrete proposal from any other jurisdiction would be fine - but we should get moving. Andreas - if you want to get involved - I believe Florian is working on a German entity proposal as another option - hopefully we see that soon. Personally I think there may be merit in a UK option still - if Simon is interested in engaging. I think we've discussed a few tests (perhaps there are more) for an entity to sell things in the app-store: * protect TDF by some effective separation ie. a different entity. * have an corporate'y structure ie. no unexpected restriction on activity * provide for effective control by TDF * provide for operational isolation from the BoD + though I'm still hopeful we can de-stress the BoD relationships over time. * have low running costs, risks, and overheads * have local people willing to file forms / documents * have English Gov't interaction so all is transparent Perhaps something else ? One of the wider problems we have I think is a lack of decisiveness. Also some sort of steady stream of people arriving late to a discussion and re-starting it =) perhaps that is inevitable as discussions ripple outwards through the community as they get more concrete. From a process perspective I think we'd want to get a deadline for short, summary proposals - perhaps under some agreed grid / headings (cf. above) - that we can present to the membership as a simple poll (we have a great ranked / voting method to handle this sort of thing). With the membership's views in hand, the board could perhaps vote to give confidence to the teams involved to get on with final preparation and the actual formation. Again - it would be lovely to help out by build a constructive, detailed alternative proposal if you can Andreas, and I imagine that would be welcome. My 2 cents, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] an Online move ...
Hi there, This is a detailed mail, so it shows up as a TLDR; then a status quo / resolution / benefits triplet, and a link to our FAQ. We're excited about this as a way to decisively unwind a number of inter-related problems at TDF. We'll keep an up-to-date version of this in the FAQ. * TLDR; Collabora announces that it will move its work on Online from TDF to GitHub https://collaboraonline.github.io/, in order to ensure future investment in the software development of Collabora Online and LibreOffice. This will allow us to deliver on many of the requests from the community and we expect that this will resolve the lengthy discussions in the TDF Board around a fair strategy for "LibreOffice online", thus freeing energy for other constructive topics. * status quo / resolution / benefits: ** status quo: background & issues + the current status of "Online" at TDF is dis-satisfying to end-users, some community members, Collabora, and it creates strain in the LibreOffice project. + Online has been substantially created, sustained and continues to be developed by Collabora investment: + Collabora's 20+ committers provided 95%+ of the commits in the last year + LibreOffice Online has been a source-only project: a place to collaborate around development, with own-branded products versions derived from that. Publicly available products have encouraged people to buy support when under heavy use. + some TDF community, board and staff members have made it clear they don't accept this compromise, and want TDF to use the LibreOffice brand to distribute a competing gratis product in the marketplace driving the price to zero, (perhaps combined with nags for donations to TDF). Others wish to ship gratis LibreOffice branded builds not immediately but in 3-6 months. + still others dislike the idea of telling users that it is essential that they contribute to the project, in proportion to their ability. Others have concerns about even gentle moral suasion here eg. around tags & naming; others around donation requests. Still others recommend proprietary software, or sale of extensions as a solution. Some claim the TDF statues require one course of action, others that they do not. + this combination of uncertain direction, structure and statutes at TDF make it difficult for an investor today to have any confidence in a future return over the years in which that takes when the Online project is hosted by TDF. + TDF has historically avoided explaining clearly how LibreOffice is created even to its own community. It does not give effective credit to the commercial community members doing most of the indispensable work in any way that can drive a proportionate return. There is little confidence in this improving. + The prospect of the Collabora brand having to compete against something we ~95% build ourselves. ie. with products sold or distributed gratis under the popular "LibreOffice" brand - while Collabora continues to sustain, maintain, and improve the software in an effectively invisible way is deeply problematic. + imagine trying to explain to larger users why they should not use LibreOffice Online, but pay for Collabora Online. Absent significant help from TDF that is incredibly hard to do in a way that doesn't damage LibreOffice as a whole. + For TDF to provide significant support fairly, in a way that rewards investment, is incredibly challenging to achieve inside TDF's structures. + There are lots of good people on all sides of this argument who come from different perspectives. Many of them are unhappy; we seem stuck in a worst of all worlds position currently. + There is an ironic tension here between wanting everything to be gratis, and wanting investment. Ultimately by making everything gratis, while not encouraging users to contribute financially, and having no credible plan to reward investment - TDF harms its own FOSS mission, which aligns well with Collabora's: to produce great FLOSS software for everyone. * TLDR; resolution: a move. + To sustain Online and to improve it requires substantial and ongoing investment and focus, far beyond what TDF can provide via nags & donations. Any returns require a stable environment. + We believe the most elegant way to resolve the strain and uncertainty is to move our existing sub-project & work around Online to a new project at Collabora.
Re: [board-discuss] MCC questions ..
Hi Daniel, On 04/09/2020 14:29, Daniel Armando Rodriguez wrote: >> * many MC members say they want to expand the membership. >> Given that LibreOffice is rather static in terms of its >> number of those involved in development: coding, UX, >> translation, documentation etc. >> >> + how do you plan to gain lots of new contributors ? ... >> + Do you think we expand the membership by accepting >> more marginal contributions for membership cf. >> >> https://wiki.documentfoundation.org/TDF/Membership_Role#Contributing > > What's the 'more marginal contributions' meaning? Ah - perhaps I should be more clear: + "Do you think we should expand the membership by accepting much smaller contributions for membership" Sorry for that. The essence of the question is simple - if you want to grow the membership there are at least these two approaches: + encourage more people to contribute more to meet the criteria or + lower the criteria for membership Hence my question - in each case - I'd love more detail on people's suggested approach. >> * How do you believe we can improve the existing election >> system - assuming the statutes can be tweaked ? >> + I'm interested in where we have the situation that >> being too popular can stop you being able to >> engage at all as a deputy - as we saw with >> Miklos/Jona in the last MC election, and Kendy >> in the last Board election. > > 'Too popular'? What about that tiny little issue called affiliation? Sure, so do you have a question about that ? either way I'm curious about MC member's views of an electoral system whereby (given the current CoI rules) discouraging people from voting for you is a good tactic to get elected ;-) and/or that if/as/when people are bumped by these rules that it's not possible to appoint the next most popular person in the ranking etc. I would hope that: "* How do you believe we can improve the existing election system - assuming the statutes can be tweaked ?" Is a legitimate question for the MC candidates ? ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] MCC questions ..
Hi Andreas,
On 03/09/2020 19:59, Andreas Mantke wrote:
> b) TDF currently has 221 members and none of them asked any question to
> the candidates!
>
> That's something to think long and hard about. What does this mean to
> the democratic culture of the foundation. It was created to get the
> members / contributors a voice and a say.
Fair enough =) good point - here are a few questions I came up with.
Please note - it is trivial to ask more questions in a few minutes than
can be answered in a lifetime - but here are a few things I'd love to know
from each candidate:
What is the right list for that ? board-discuss I hope.
* many MC members say they want to expand the membership.
Given that LibreOffice is rather static in terms of its
number of those involved in development: coding, UX,
translation, documentation etc.
+ how do you plan to gain lots of new contributors ?
+ Do you think we expand the membership by accpting
more marginal contributions for membership cf.
https://wiki.documentfoundation.org/TDF/Membership_Role#Contributing
+ what effect do you expect that to have on the project ?
* If you've stood before, approximately how many people have
you encouraged to apply for membership ?
* How many applications have you voted against ?
* Do you believe we should have a half-way house / badge
between membership and non-membership that encourages
a person, and gives the a path via more contribution to
achieve full membership ?
* When there are no concrete metrics (such as translated strings,
code commits, wiki changes, ask comments, etc.) available to
decide on a person's contribution; what is best practice for
MC members vouching for their friends' contributions, and how
should other MC members validate that ?
* To what degree should the MC's decisions & discussion
be transparent (ie. publicly available) ?
* How do you believe we can improve the existing election
system - assuming the statutes can be tweaked ?
+ I'm interested in where we have the situation that
being too popular can stop you being able to
engage at all as a deputy - as we saw with
Miklos/Jona in the last MC election, and Kendy
in the last Board election.
Thanks for any answers =)
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Initiative to improve communication channels
On 17/07/2020 18:52, Daniel Armando Rodriguez wrote:
> Well, misunderstanding of ideas can be avoided simply by communicating
> in such a way that no aspect is taken for granted when making the
> request for feedback.
I have no problem with tools to get polls / feedback from our userbase;
that's great =)
Of course, for decisions - we are a meritocracy^W doers-decide project;
so having some separate means for the members to easily inform the board
/ discuss and/or give their input / views on things would also be
extremely valuable. Hopefully some clear separation would make
membership - and more importantly the contribution necessary to achieve
it more attractive to people too (perhaps).
My 2 cents,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Big organisations not contributing
On 14/07/2020 12:22, Sophi wrote:
> There is another item here, I know several orgs buying services from
> companies that are not good players with FLOSS communities. This is
> something in my view which is important to address
Absolutely. So - the original plan here was not just just to do a
"Fedora vs. RHEL" style marketing separation of LibreOffice derived
products - but to ensure that the "LibreOffice Enterprise" side of this
- could only be used in products backed by a suitable number of a
combination of (say the average):
* certified developers
* contributing developers
by providing a clear economic incentive and a distinct postioning we
can simultaneously highlight those who take but don't contribute, and
also provide a clear economic incentive for them to contribute.
> Finding ways to expend the ecosystem is vital too.
Exactly - so of course, where there is an economic incentive,
investment and hence more developers, a wider ecosystem etc. follows
behind =)
I believe Bjoern sketched a similar idea in his recent mail too =)
Clearly - we need more time to elaborate & communicate how all of those
pieces could fit together to make something that drives TDF's mission
like a rocket ship =)
HTH,
Michael.
--
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
--
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
Re: [board-discuss] Re: Some problems.
Hi there, I thought I'd pull together a thread that runs through a subset of the comments here: Here is Mark S writing in bugzilla: > Let LibreOffice stay LibreOffice, and let any commercial derivatives > deal with naming issues of their products on their own time. Several other comments are more of the form: "your problem, not mine", or "TDF doesn't need to nurture an ecosystem - why complain to TDF" ? So - of course, that is on one hand fine. Hypothetically TDF could sit at the center of a pure volunteer project, perhaps with enough mentors and enough donations that might work out (though on current trends this might also result in a project a tenth of the size). On the other hand getting there from here, while not loosing all momentum would be wrenchingly problematic. I guess there are some elaboraions of this: On 15/07/2020 14:11, Telesto wrote: > The 'free beer' argument starting to become annoying;-). I'm hearing > lots of self-pitty. > Nobody asks a company to contribute to the LibreOffice code (for free). > Yes, it belongs to a model where you believe in. > If you believe code be open source, while making profit, it's also your > task to come up with a business model generating revenue. Sure, so - it's a harsh market. TDF can choose to make it harsher by competing with the ecosystem that creates much of the LibreOffice code, and mentors much of the developer community. Or it can be passive and do nothing to nurture investment. Or it can create space for those that contribute to its mission and help out. Having a clear approach is helpful though. One of the problems is ambiguity: bait & switch: encourage the investment, but squash the returns by changing the rules =) That is why having a long-term settled consensus is really helpful. > The world is hard and pretty unfair. Indeed, on the other hand - my hope is that we shouldn't use that as an argument to structure things to be deliberately unfair. To a large degree TDF helps to seed the environment for the ecosystem to flourish around the codebase and fulfill its mission with it. Arguably (and I would say this) TDF cannot fill every niche, and serve every market itself - for a host of reasons. On 14/07/2020 16:07, toki wrote: > On 2020/07/14 10:41, Michael Meeks wrote: >> On 12/07/2020 20:32, toki wrote: >>> I'd blame the lack of sales on Collabora having a really bad website >> >> So, if getting sales is only a function of a really good website > > I think it was Brian Tracy who wrote if your website can't sell the > qualified prospect, it needs to be redesigned. I think we're all hopeful that we can create an advert or webpage that makes it impossible not to buy your product ;-) Brian's quote mentions qualified prospects - that's much easier with a sensible lead flow of people who are aware that you exist. >> Beyond that - creating, maintaining and translating a website into >> a handful of languages is an expensive hobby. > > Budget US$100,000 per language per year, for a multilingual website. > This is addition to the cost of designing and maintaining the website. > Before adding languages, look at both the financial ROI, and PR value. > Will the language generate at least US$1,000,000 in additional business > each year ? Well, for our existing ~five languages - if we did that we'd have to transition half of our development staff to marketing at some significant loss to Free software; I assume you'll want a big budget for paid multi-language advertising to bring people to that website, and for sales people too to qualify the leads ? That would consume our entire budget without any contribution back. Either way - given that the same website sells Online but not Desktop, despite advertising both, my suggestion would be that making people aware that they shouldn't be running large un-supported deployments - is a leading factor here. > The last thing any business owner wants to hear from a current > customer is "I went with company x, because I didn't know you > provided that service." I think that's the fundamental problem here; getting the word out effectively that the services around LibreOffice exist, and that buying them is good for the customer, good for the codebase, so good for all our users, and good for the community. ATB, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
