Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Hi Marco, see below. On 09/01/2022 17:05, Marco Marinello wrote: Based on this two quotes, I’d like to make a counterproposal for the online project: 1. Since not only Collabora-affiliated developers but almost everybody that was previously involved in development of Online moved on Github, contributing to Collabora’s repo, TDF should publicly endorse this choice, stating that the project is now hosted on Github and the development is managed by a company of the ecosystem but is – at the end of the day – always LibreOffice Online. I don't think TDF can and should endorse or promote third party products as I think you proposed. Collabora made the choice of moving what was LOOL away from TDF infrastructure and made a considerable effort to remove as much as possible the references to the fact that it was a shared project (removing "This file is part of the LibreOffice project", renaming variables from LOOL to COOL, etc.). Unfortunately what is in that GitHub repository is not LOOL any more so, IMHO, it has little to do with TDF now. 2. Provide stable libreoffice-branded builds (on a nightly/weekly basis) of LibreOffice Online on the Docker HUB (possibly also DEBs/RPMs) starting from the Collabora repository. This can either be done internally by TDF or tendered. True, we could even backport the lot and rebrand it but I believe TDF should lead by example by confirming that, while it would be only fair for the other party to actually deliver their side of the agreement, we don't want to damage any valuable member of the ecosystem by cloning their product as it is. As said in other threads, negotiations for a mutually beneficial agreement were ongoing before they decided to go their own way and it's up to them to recognise that their actions went against what TDF and the LibreOffice community stand for and eventually come back to the negotiation table. If Collabora decides to backport to TDF's LOOL repository or agrees that it's fair for TDF or external partners to do it then we could consider it. 3. Update the documentation at TDF’s wiki. As above, internally done, volunteered or tendered. Before updating the documentations we should know in relation to what, the outdated LOOL we have in the repository or a product that is not LOOL any more? 4. Grant, as already happens e.g. for Play Store / Windows app store, the permission to release the builds with the “LibreOffice Online” trademark to companies of the ecosystem that ask for that. I'm not fully sure about it as it may lead to the same difficult situation we have now with LOOL. If companies of the ecosystem would like to contribute to LOOL hosted by TDF this time it should be done under a clear agreement, the one also proposed for the "de-atticisation" process, so that the LibreOffice community will also benefit from it. If they should be allowed to use the "LibreOffice Online" name is something to discuss as I think all members of the ecosystem should find ways to differentiate themselves in terms of brand and services they provide. Then we could evaluate if they could use the LibreOffice Technology brand while they use LibreOffice projects hosted by TDF to which they actively contribute. This 4 bullet points would allow, at least in my opinion, TDF to acknowledge Online as “still part of the LibreOffice ecosystem” and continue with his distribution/marketing, in order to build a real market surrounding LOOL. I believe it's clear to most that LibreOffice Online is the original project hosted by TDF which should have led to a platform freely usable by anyone under. The issue now is how to bring it back to a state where people can actually use it. Let's also keep in mind that while you can create Marco's Office that anyone can download and use, LOOL needs a more complex setup. I believe that ownCloud, NextCloud and others would have accepted to add LOOL by TDF as a free community option to their marketplace to make it easier for non IT specialists to use but otherwise it is not that simple to deliver to the users. All the best, Marco Maybe others from our community have other ideas and comments for these proposals? Ciao Paolo -- Paolo Vecchi - Deputy Member of the Board of Directors 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 OpenPGP_signature Description: OpenPGP digital signature
[board-discuss] Agenda for TDF board meeting with invited elected board members on Friday, January 14th at 1300 Berlin time (UTC+1)
Dear community, find below the agenda for our -> TDF board meeting with a public part and followed by a private part -> on Friday, January 14th at 1300 Berlin time (UTC+1) For time zone conversion, see e.g. https://www.timeanddate.com/worldclock/converted.html?iso=20220114T13=37=136=241=589 -> at https://jitsi.documentfoundation.org/TDFBoard We meet on Jitsi, and please, if possible use Chrome browser and do not use video and until not speaking up please mute. -> AGENDA: Public Part 1. Introduction: Welcome to the new elected board members and invitation for the next meetings and to stay with us in private parts (Florian, 5min) Rationale: Introduction in the transition phase and onboarding information 2. Q: Answering questions from the community (all, 10 minutes) Rationale: Provide an opportunity for the community to ask questions to the board and about TDF 3. Information: Suggestion of an "attic" procedure (input from subgroup, status of discussion) and status of LOOL repository (Thorsten, Emiliano, all 20min) Rationale: Status/Follow on of the action items (procedure, LOOL), timeline for decision making on that 4. Information & Discussion public part: status of 2022 budget suggestions (Florian, all 10min) Rationale: Planing for finalizing and handing over to new board Private Part 5. Information & Discussion private part: status of 2022 budget sheet and procedure of decision making (Florian, all 10min) Rationale: Planing for finalizing and handing over to new board 6. Discuss: Last minute item(s) (owner of the item, all 5min) Rationale: if there is popping up an item after sending the agenda - No more topic in private so far - -- Stephan Ficht, Administrative Assistant Tel: +49 30 5557992-64 | Mail: stephan.fi...@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] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
About the severity to overrule the ESC we are on the same side, a board should think twice or even more if doing so. But without clarification these two sentences set the expectations that an ESC have a blocking decision which is in fact wrong as you say by your own. And in such a case to lean on exchanging the ESC afterwards is a questionable move then, isn‘t it? So lets discuss on Friday as it is already on the board meeting agenda. Perhaps with a little clarification as I proposed we could improve this text of the procedure. Thanks Lothar Von meinem iPhone gesendet > Am 10.01.2022 um 16:16 schrieb Michael Meeks : > > >> 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 >
