Update to today's call agenda

Dear community,

find below a quick update to today's call agenda:

* Wrt. item #4 (vote proposal), this item will be turned into a discussion item. The rationale for this is that more input from the community is sought, before the item can be turned into a vote. We will in parallel get input from the infra team on this topic.

* Additionally, a conflict of interest accusation was made. The board will discuss this internally first. As that item arrived too late to be considered for today's formal agenda, the discussion might take place before or during the next meeting. Further information will be published in accordance with our statutes.

* Wrt. updates about the status of a business entity, the board currently finalizes a statement that will be sent out to the community within the next days.

Florian

Hi Florian,

It looks as if you missed my mail from this morning. That's unfortunate.
But, can you please help me:

* Additionally, a conflict of interest accusation was made. The board

Who made that accusation, where and when?

Thanks a lot for you help :wink:

Cor

Thanks for this change, which seems appropriate.

With a view towards making LibreOffice Online (LiOn for short!) available to as many members of our community as possible without inadvertently harming TDF’s own members in th eprocess, I propose TDF first make it available for Raspberry Pi. I have written a brief paper explaining the idea, which I have placed in the Members folder here:
https://nextcloud.documentfoundation.org/s/mboT66dRtdEMMyq

Best regards

Simon

I'd like to collect experiences on deployment LOOL as it's offered right now and what people think need to be improved.

I believe we should know what people expects when downloading a docker img, if it fits the needing or what do they have to deal with.

Hi Daniel, all,

Daniel Armando Rodriguez wrote:

I believe we should know what people expects when downloading a
docker img, if it fits the needing or what do they have to deal
with.

Depends on who's the target audience of that question, I guess.

Possibly the design, or the website list are better places to discuss
this?

Cheers,

-- Thorsten

A survey form would be the best way to go about it.

Also note that - regardless of package availability - as conceived Libreoffice Online is beyond the scope of most individuals as it requires access to cloud infrastructure, familiarity with certificates and a willingness to manage web security. That’s why I have proposed LiOn Pi, which is targeted at individuals.

S.

{Terse? Mobile!}

Happy to support this but no idea how to start. Ordinary users cannot answer "What's the best solution for you to get LOOL?" neither "Which kind of authentication do you prefer? [OpenFoo, LibreBar, PublicQux]". And isn't the setup kind of a stack that needs to be installed with (Next)Cloud, LOOL backend, and (COOL)-UI?

So what I'd need for a survey is a couple of simple questions that everybody can answer. My preferred type of question is multiple-choice with additional "Other" option.

Hi Daniel, all,

Daniel Armando Rodriguez wrote:

I believe we should know what people expects when downloading a
docker img, if it fits the needing or what do they have to deal
with.

Depends on who's the target audience of that question, I guess.

Members, Certified Professionals, sysadmins

In this case our end user should understood, IMO, be Certified professionals, members or IT responsible people.

So, maybe this thread can drop such questions as a result.

A survey form would be the best way to go about it.

Also note that - regardless of package availability - as conceived Libreoffice Online is beyond the scope of most individuals as it requires access to cloud infrastructure, familiarity with certificates and a willingness to manage web security. That's why I have proposed LiOn Pi, which is targeted at individuals.

At least a sysadmin would be willing to deal with, but as far as I know currently is hard enough even for such profiles.

Hi Heiko, all,

Heiko Tietze wrote:

So what I'd need for a survey is a couple of simple questions that
everybody can answer. My preferred type of question is
multiple-choice with additional "Other" option.

Thus my (perhaps unintuitive) suggestion to start discussing the
details on the design list - Daniel already listed a number of
different personas (members, certified professionals, and sysadmins),
and it is not unreasonable to assume they might have different needs.

Cheers,

-- Thorsten

The point has to do with the smooth process they/any must find when deploying such a solution.

On Fri, May 22, 2020 at 4:37 PM Daniel Armando Rodriguez <drodriguez@documentfoundation.org> wrote:

El 2020-05-22 10:33, Heiko Tietze escribió:

On 22.05.20 16:09, Simon Phipps wrote:

A survey form would be the best way to go a about it

Happy to support this but no idea how to start. Ordinary users cannot
answer “What’s the best solution for you to get LOOL?” neither “Which
kind of authentication do you prefer? [OpenFoo, LibreBar, PublicQux]”.
And isn’t the setup kind of a stack that needs to be installed with
(Next)Cloud, LOOL backend, and (COOL)-UI?

So what I’d need for a survey is a couple of simple questions that
everybody can answer. My preferred type of question is multiple-choice
with additional “Other” option.

In this case our end user should understood, IMO, be Certified
professionals, members or IT responsible people.

So, maybe this thread can drop such questions as a result.

That is not acceptable. We should be serving the public, not a technical elitre.

S.

Hi all,

in September 2019, to get another project up and running (in which the
main component is NextCloud), I found myself working on LibreOffice Online.

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written "Left as an exercise to
the reader") was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

I experienced how the community was once helpful (e.g. addressing me to
the l10n-docker-nightly and explaining the branches) and once, let's
say, less helpful (quote from the IRC "and why do you think we
(Collabora) would want to help you in creating a competing product?").
Needless to say, this has left me stunned: certainly if I write to the
community I don't expect someone to judge if I'm able to declare a
variable in Javascript or not.

Since then, however, much has been done: Online now has at least a
decent documentation which covers the build of a stable version of the
docker container. Many information are though still missing, a reliable
evaluation of the resources needed to have a stable instance and how
many users it could serve, for example. Clustering LOOL even seems to be
an untouched topic for now (to the public, at least).

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

I even agree with Simon: deploying online is horribly hard. I've been
working on some Ansible playbook since a while and I think they could be
soon released. The aim is to provide sysadmins (even myself) an easy way
to deploy LOOL. If we have on the Docker HUB an arm64/amrhf image,
having it working on a RaspberryPi would be just a side effect.

All the best,

Marco

Hi Marco,

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

Thanks for bringing this forward and good to see a future contributor
possibly :wink:

What you say, is a clear statement, that we all - the full community -
will think and discuss about when the 'start document', that has been
decided in today's board meeting. I hope that can be ready soon, since
it's a very important and hot topic. I hope you also appreciated the
other parts of the meeting of course.

Greetings,
Cor

Cor Nouws kirjoitti 22.5.2020 klo 22.15:

Hi Marco,

Therefore, I totally endorse Paolo's proposal. TDF should, in my
opinion, definitely release working stable binaries of online. Many many
associations out there don't have the money or simply don't need a
professional support just the same way it happens for the client version.

Thanks for bringing this forward and good to see a future contributor
possibly :wink:

Marco has already written docs in the wiki for some months:
https://wiki.documentfoundation.org/Development/BuildingOnline
https://wiki.documentfoundation.org/Configuring_a_reverse_proxy_for_LOOL

Ilmari

Hi,

This was totally a pain. The lack of any consistent documentation (until
May 5 in the INSTALL file there was just written “Left as an exercise to
the reader”) was one of the biggest problems. The only way was to rely
on old blog posts found on the internet.

Until recently the consensus was that TDF releases source tarballs for LOOL. So there was no demand to write documentation how to create packages, how to build a “product”.

On the other hand it is fully documented in the source code in README files how to build as a developer, if someone wanted to hack on the code.

The docker/l10n-docker-nightly.sh is also quite self-explanatory. (For those, who don’t know what it is: it builds a docker image from source.)

Another totally undocumented topic (obviously I refer to the official
documentation on wiki.documentfoundation.org) was the configuration of a
reverse proxy to work with LOOL, essential since configuring LOOL to use
a non-self signed certificate is even harder.

As TDF did not release binaries, I don’t know who would look for such documentation in TDF wiki. Collabora published documentation for CODE, e.g.:

https://www.collaboraoffice.com/code/apache-reverse-proxy/
https://www.collaboraoffice.com/code/nginx-reverse-proxy/

But there are other good sources of information, too, from integrators.

I even agree with Simon: deploying online is horribly hard. I’ve been

I disagree. It’s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It’s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my “5 minute” guides?

https://www.collaboraoffice.com/code/quick-tryout-owncloud-docker/

https://www.collaboraoffice.com/code/quick-tryout-nextcloud-docker/

Regards,
Andras

Hi!

I disagree. It’s a myth. Yes, it can be hard, when firewalls, load balancers, 50000 users etc. are involved. It’s the case when one needs professional support. But for the hobbyist, how hard is it to install CODE with a few clicks in Univention, or to follow my “5 minute” guides?

I’m sure you have done a great job for suitably-skilled people wanting a quick evaluation, but the truth is that approach only takes you to the point where the questions start. I have tried to get a LiOn system running at home and have not succeeded in getting anything I can leave running for my family, unlike the Asterisk-based phone system we are using (on a Pi) or the NextCloud appliance we have installed (Pi-based).

This is the LiOn problem TDF needs to fix first to get a TDF-centric user- and skill-base established.

S.

That's a missleading, those profiles can help us to reach the endusers.

My personal take is we should get a product as easy to deploy as WordPress, for instance, to let the end user take the control of their own cloud.

Thank you for valuable input Marco

What makes my worry is the response you got about C'bora under TDF's IRC

And I take you words "an easy way to deploy LOOL" should be provided by TDF, as TDF's mission is to offer a free product to the end user. And that offer should allow a painless implementation.