Re: This Project has no future!

[Dominik Ruf]

Sorry for the late response, but I wanted to give more people (especially
Mads) the chance to respond as well.

But sadly he didn't. I mean, I claimed that this project faces an
existential crises. And yet, the project lead doesn't even bother to
respond. Sorry, but this is the last nail in the coffin of this project.

Thomas De Schampheleire  schrieb am Di., 10.
Apr. 2018 um 22:05 Uhr:

> Hi Dominik,
>
> 2018-04-09 20:08 GMT+02:00 Dominik Ruf :
> > Hi all,
> >
> > I was in denial in the past years. But it is time to face the facts. This
> > project isn't going anywhere.
> > About a year ago I already expressed my worries, but next to nothing has
> > changed since. There are still pull requests that are multiple years old.
> >
> > For example, my bootstrap PR is still not pulled completely. There is
> still
> > a discussion about whether (and how) we should use minification and
> source
> > maps.
> > These are technologies that practically every web application in the
> world
> > are using. So this should be a no-brainer. And yet, after more then 2
> years
> > we discuss if adding the source map flag should be in a separat
> changeset.
> > Seriously guys, this could be in the dictionary as the very definition of
> > bikeshedding.
>
> I'm sorry you feel this way.
>
> I don't agree that the project is not going anywhere or it has no future.
> It's just so that at this moment the pace of development is quite slow
>
It is slow for years.

> because we are near the end of the bootstrap PR

Even the progress for the bootstrap PR is slow.

> , and there are some
> changesets where there is still a discussion. It is not so much about
> whether or not to use minification or source maps. There was some
> unclarity on how the source map actually works and whether the feature
> was complete, that is clear to me now.
>
And it took you more then 2 years to ask about it!?
BTW I don't think it is my job to explain basic web technologies in a
commit message.

> There is also an open point about the 'watch' feature and whether or
> not it should be integrated in gearbox --reload rather than
> introducing a new 'nodemon' mechanism.
>
It'd be a legitimate question whether to use gearbox to generate the less
files. But after more then 2 years the time to discuss this has passed.
And like I said, stop making the better the enemy of the good.
If there were really go reasons to use gearbox we could still implement
that later. Adding 'nodemon' (or remove it) is not a big deal.

> The introduction of 'npm run X' has also raised some comments in the
> past regarding cross-platform support. These is IMHO not bikeshedding,
>
The bikeshedding refereed to the source map flag that you wanted in a
separate changeset. If you really think it must be in its own changeset,
then just move it there and don't waste another communication cycle. It is
not worth discussing about.

> it's about being careful in adding extra complexity or going in a
> wrong direction.


> There are other examples of changes that go through quickly and
> without a lot of problem.

Yes, I also had some trivial changesets that went through quickly. But that
is not the point. We talk about the big important stuff.

> Examples are the changes regarding 'issue
> references' (issue_pat and friends), the refactoring of the VCS test
> classes, and the recent update to V2 reCaptcha.
>
I don't know about this, I can't see the changes in the bitbucket PR
anymore. But I guess it did not involve any difficult decisions. And that
is where the problem occur.

>
> Regarding clean commits: it is an explicit part of the project
> culture. From the docs/contributing.rst file:
> "We care about quality and review and keeping a clean repository
> history."
>
> You have made clear in the past that you think this is often a waste
> of time, but I disagree (and I'm pretty sure Mads does too). A clean
> repository history is invaluable both during review, as during future
> changes, to understand why something was done.
> It would save time and frustration from all people involved if all
> contributors take along this principle from the start when designing
> and ordering commits. If you think from the start how your commit path
> will be, the lost time is minimal.

Sorry, but you should know that this is not always possible.
The current history does not represent the natural way how the bootstrap
stuff evolved. There is no way that I could anticipated the changes from
the beginning.

> And when these commits are small
> and well documented in the commit message, then review will be much
> easier.
>
I will admit that my commit messages were not very detailed at the
beginning (quite often I believed it was just not necessary). But fine, I
see some value in it and my commit messages are more detailed now. But
again this is not what I'm criticizing here.

> I'm glad that you split up the one big remaining bootstrap commit 'in
> small parts', 

Re: This Project has no future!

[Dominik Ruf]

Long Vu  schrieb am Di., 10. Apr. 2018 um 16:17 Uhr:

> On Mon, Apr 9, 2018 at 2:08 PM, Dominik Ruf  wrote:
> > Hi all,
> >
> > I was in denial in the past years. But it is time to face the facts. This
> > project isn't going anywhere.
>
> I am sad to hear this.  Kallithea is about the only *completely open
> source* all in one repo management, code review tool that also support
> Mercurial.
>
> Mercurial needs more tooling support.  Git is more popular not because
> Git itself is easier to use or have more features or can enable more
> workflows (Mercurial Evolve extension beat Git lightweight branching
> and server-side history rewriting by a long shot).
>
> Git is simply more popular because of the tooling support.  Tooling
> support is something Kallithea brings to the table.
>
I completely agree. That is also the reason why I worked on this project
and stayed so long.

>
> > About a year ago I already expressed my worries, but next to nothing has
> > changed since. There are still pull requests that are multiple years old.
> >
>
> I am guilty of this as well.  I have 1 or 2 PR that has been sitting
> there for over a year, or almost 2 years (ouch), simply because I have
> not had time to polish them for re-submission.
>
> > For example, my bootstrap PR is still not pulled completely. There is
> still
> > a discussion about whether (and how) we should use minification and
> source
> > maps.
> > These are technologies that practically every web application in the
> world
> > are using. So this should be a no-brainer. And yet, after more then 2
> years
> > we discuss if adding the source map flag should be in a separat
> changeset.
> > Seriously guys, this could be in the dictionary as the very definition of
> > bikeshedding.
> >
> > What troubles me the most about this, is the lag of communication. It
> > sometimes takes weeks or even month to get any kind of feedback.
> > I understand that people are busy, but as a leader of a project like this
> > you should at least drop a quick sorry note and say when you will be
> able to
> > look into the thing. Or delegate!
> >
> > And I'm not the only one who has this problem. Our bitbucket is full of
> old
> > PRs that went nowhere. Take the ssh PR for example. That one is 3.5 years
> > old! I believe most of those people just gave up.
> >
> > I really believed this project had potential. But all my attempts to
> improve
> > the communications or the projects organisation have been ignored. And my
> > PRs were treated purely and very slow.
> >
> > What needs to change:
> > - Stop pondering if some small change should be its own changeset
> > This wastes A LOT of time. The quality of the code needs to have a higher
> > priority then the quality of the changeset history!
>
> Just my 2 cents here, using Mercurial Evolve, it's super easy to
> change changeset history.
>
I/we already use evolve. But even though it is easy, it still burns a lot
of time. It is not so much time spend to do actual work, but waiting for
feedback for the next iteration. Because changes are easily made it looks
cheap, but in the end it isn't.

>
> I agree that changeset history is not a hard requirement but a very
> good nice to have if time allows.  Make the job of the reviewer easier
> and then the review can review more and give faster feedback.
>
Yes, but it comes the point where it is more work to re-do the changes,
then it helps the reviewer.

>
> Long term, it can help training new developper as well.  When working
> on new area of the code, I tend to annotate, dig the history the few
> files I think I will need to modify, just to see what kind of past
> features, bug fixes also touched these files so I know what kind of
> impact my change will induce and plan testing accordingly.  Too big a
> past commit and I will just get that something in the past needed this
> area of the code but not precisely why so it's harder to understand
> the implicit dependencies.
>
But in this case it doesn't help if the past changes have been split into
multiple smaller ones, does it? Having more, smaller changes means you'll
have to look at more changesets, which makes it more cumbersome. doesn't it?

>
> > - Stop making the 'better', the enemy of the 'good'.
> > If somebody comes up with a better solution in the future, great, but up
> > until then settle with the good solution you have now.
>
> Agree with that one.
>
> > - Start using JIRA to manage and prioritize the open issues, PRs and
> other
> > tasks.
>
> Doesn't necessarily have to be JIRA but any kind of project management
> tool is good.  I remember someone on this list was considering redmine
> or another newer tool with lots of potential.  Completely open-source
> tool is preferred of course but maintenance and support effort have to
> be considered.
>
I don't think redmine comes even close to JIRA in perms of user
friendliness. But the important thing is that the people in charge actually
do 

Re: This Project has no future!

[Alessandro Molina]

On Thu, Apr 12, 2018 at 10:52 PM, Thomas De Schampheleire <
patrickdeping...@gmail.com> wrote:

> Hi Alessandro,
>
> Thanks a lot for this information.
> If I understood correctly you wouldn't even need npm at all, correct?
>

Yes, that's correct.
npm nor node are required. Dukpy tries to replace them both.


> Do you know of an example project that is using this?
>

I used it on some closed source projects, mostly to compile ES6 and JSX.


> Where would you handle this bundle creation and nodejs downloads? From
> setup.py? From a gearbox command?
>

I usually go through webassets itself which creates the bundle and caches
it on application startup.
But I also wrote fabric based scripts for command line in a few projects
where no backend was involved.

Both gearbox and setup.py would be perfectly reasonable solutions to
compile those. I'd say I have no strong opinion on how this should happen
and I change it from project to project myself according to the needs of
the project. The approach of going through tgext.webassets is very
convenient because it happens automatically on app startup and nothing has
to be done, but it should be easy to contribute a command to
tgext.webassets to precompile those bundles.

And do you have suggestions with respect to the handling of external
> asserts when creating a pypi package, in particular taking into account
> licensing aspects of the GPL (Kallithea is a gplv3 project).
>

I usually predownload them an ship them in a ./js_modules directory within
the project as far as the license allows it.
While it's in theory possible to have dukpy download the requirements on
install through setup_requires, I never did it in practice.

Some time ago I wrote a short article to showcase how dukpy could be used
to compile JSX which also creates a javascript bundle for the app:
https://medium.com/@__amol__/es2015-and-react-in-pure-python-environment-b326dc15012c
It might help giving a better understanding of the whole thing.
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: This Project has no future!

[Thomas De Schampheleire]

Hi Alessandro,


On Wed, Apr 11, 2018, 11:41 Alessandro Molina 
wrote:

>
>
> On Tue, Apr 10, 2018 at 10:04 PM, Thomas De Schampheleire <
> patrickdeping...@gmail.com> wrote:
>
>>
>> There is also an open point about the 'watch' feature and whether or
>> not it should be integrated in gearbox --reload rather than
>> introducing a new 'nodemon' mechanism.
>> The introduction of 'npm run X' has also raised some comments in the
>> past regarding cross-platform support. These is IMHO not bikeshedding,
>> it's about being careful in adding extra complexity or going in a
>> wrong direction.
>
>
> Hi Thomas,
>
> If node is just involved in compiling js/css and bundling assets you might
> want to have a look at
> https://github.com/amol-/dukpy
>
> It's a project that I created exactly to avoid the need to have two
> dependency managers (npm and pip)
> and two execution environments (python and node) for a Python web app.
>
> It has a builtin less compiler (
> https://github.com/amol-/dukpy#less-transpiling ) which is integrated
> with WebAssets ( https://webassets.readthedocs.io/en/latest/ ) to
> generate css bundles out of less files without the need to install
> node/lessc.
>
>
> And through support for npmjs.org (
> https://github.com/amol-/dukpy#installing-packages-from-npmjsorg ) it's
> in theory possible to have setup.py also install node dependencies.
>

Thanks a lot for this information.
If I understood correctly you wouldn't even need npm at all, correct?

Do you know of an example project that is using this?
Where would you handle this bundle creation and nodejs downloads? From
setup.py? From a gearbox command?

And do you have suggestions with respect to the handling of external
asserts when creating a pypi package, in particular taking into account
licensing aspects of the GPL (Kallithea is a gplv3 project).

Thanks,
Thomas
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: This Project has no future!

[Alessandro Molina]

On Tue, Apr 10, 2018 at 10:04 PM, Thomas De Schampheleire <
patrickdeping...@gmail.com> wrote:

>
> There is also an open point about the 'watch' feature and whether or
> not it should be integrated in gearbox --reload rather than
> introducing a new 'nodemon' mechanism.
> The introduction of 'npm run X' has also raised some comments in the
> past regarding cross-platform support. These is IMHO not bikeshedding,
> it's about being careful in adding extra complexity or going in a
> wrong direction.


Hi Thomas,

If node is just involved in compiling js/css and bundling assets you might
want to have a look at
https://github.com/amol-/dukpy

It's a project that I created exactly to avoid the need to have two
dependency managers (npm and pip)
and two execution environments (python and node) for a Python web app.

It has a builtin less compiler (
https://github.com/amol-/dukpy#less-transpiling ) which is integrated with
WebAssets ( https://webassets.readthedocs.io/en/latest/ ) to generate css
bundles out of less files without the need to install node/lessc.


And through support for npmjs.org (
https://github.com/amol-/dukpy#installing-packages-from-npmjsorg ) it's in
theory possible to have setup.py also install node dependencies.
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: This Project has no future!

[aurelien]

Thomas De Schampheleire  writes:

> Hi Dominik,
>
> 2018-04-09 20:08 GMT+02:00 Dominik Ruf :
>> Hi all,
>>
>> I was in denial in the past years. But it is time to face the facts. This
>> project isn't going anywhere.
>> About a year ago I already expressed my worries, but next to nothing has
>> changed since. There are still pull requests that are multiple years old.
>>
>> For example, my bootstrap PR is still not pulled completely. There is still
>> a discussion about whether (and how) we should use minification and source
>> maps.
>> These are technologies that practically every web application in the world
>> are using. So this should be a no-brainer. And yet, after more then 2 years
>> we discuss if adding the source map flag should be in a separat changeset.
>> Seriously guys, this could be in the dictionary as the very definition of
>> bikeshedding.
>
> I'm sorry you feel this way.

I am sorry that the only public free in price and freedom project that
have been launch have been immediately killed by people of git because
it use the name git ... in a way we should all stop to respire
... someone get the name air ;-)

> I don't agree that the project is not going anywhere or it has no future.
> It's just so that at this moment the pace of development is quite slow
> because we are near the end of the bootstrap PR, and there are some
> changesets where there is still a discussion. It is not so much about
> whether or not to use minification or source maps. There was some
> unclarity on how the source map actually works and whether the feature
> was complete, that is clear to me now.
> There is also an open point about the 'watch' feature and whether or
> not it should be integrated in gearbox --reload rather than
> introducing a new 'nodemon' mechanism.
> The introduction of 'npm run X' has also raised some comments in the
> past regarding cross-platform support. These is IMHO not bikeshedding,
> it's about being careful in adding extra complexity or going in a
> wrong direction.
>
> There are other examples of changes that go through quickly and
> without a lot of problem. Examples are the changes regarding 'issue
> references' (issue_pat and friends), the refactoring of the VCS test
> classes, and the recent update to V2 reCaptcha.
>
> Regarding clean commits: it is an explicit part of the project
> culture. From the docs/contributing.rst file:
> "We care about quality and review and keeping a clean repository history."
>
> You have made clear in the past that you think this is often a waste
> of time, but I disagree (and I'm pretty sure Mads does too). A clean
> repository history is invaluable both during review, as during future
> changes, to understand why something was done.
> It would save time and frustration from all people involved if all
> contributors take along this principle from the start when designing
> and ordering commits. If you think from the start how your commit path
> will be, the lost time is minimal. And when these commits are small
> and well documented in the commit message, then review will be much
> easier.
> I'm glad that you split up the one big remaining bootstrap commit 'in
> small parts', like we asked. Honestly, I think it was the only way
> forward, and thanks to your cooperation we landed already a big part
> of it.
>
>>
>> What troubles me the most about this, is the lag of communication. It
>> sometimes takes weeks or even month to get any kind of feedback.
>> I understand that people are busy, but as a leader of a project like this
>> you should at least drop a quick sorry note and say when you will be able to
>> look into the thing. Or delegate!
>
> I agree that this is a weak point at the moment, and that we should
> improve here.
>
>>
>> And I'm not the only one who has this problem. Our bitbucket is full of old
>> PRs that went nowhere. Take the ssh PR for example. That one is 3.5 years
>> old! I believe most of those people just gave up.
>
> It's true that we need to pick up these old PRs or reject them. This
> was agreed upon already a long time ago.
> But the total bandwidth is limited, number of contributors is small,
> so you can only do one thing at a time.
> In the release 'roadmap' I proposed earlier [1] I suggested to finish
> the bootstrap changes and then make a release 0.9, and shortly after
> 1.0.
> At that point, I think we should try to reduce the open backlog. But
> it makes no sense in trying to clean up the old backlog if the current
> active PRs like bootstrap are not yet finished. It would only disperse
> focus of all people involve, and slow down the bootstrap PR.
>
> This is also the reason why I'm currently not actively looking at your
> other PRs (like 'various changes' and 'hooks'): it would move away
> focus from what we said is first priority. Just like you, I would like
> to get over bootstrap as soon as possible so we can move on.
>
>>
>> I really believed this project had 

Re: This Project has no future!

[Thomas De Schampheleire]

Hi Dominik,

2018-04-09 20:08 GMT+02:00 Dominik Ruf :
> Hi all,
>
> I was in denial in the past years. But it is time to face the facts. This
> project isn't going anywhere.
> About a year ago I already expressed my worries, but next to nothing has
> changed since. There are still pull requests that are multiple years old.
>
> For example, my bootstrap PR is still not pulled completely. There is still
> a discussion about whether (and how) we should use minification and source
> maps.
> These are technologies that practically every web application in the world
> are using. So this should be a no-brainer. And yet, after more then 2 years
> we discuss if adding the source map flag should be in a separat changeset.
> Seriously guys, this could be in the dictionary as the very definition of
> bikeshedding.

I'm sorry you feel this way.

I don't agree that the project is not going anywhere or it has no future.
It's just so that at this moment the pace of development is quite slow
because we are near the end of the bootstrap PR, and there are some
changesets where there is still a discussion. It is not so much about
whether or not to use minification or source maps. There was some
unclarity on how the source map actually works and whether the feature
was complete, that is clear to me now.
There is also an open point about the 'watch' feature and whether or
not it should be integrated in gearbox --reload rather than
introducing a new 'nodemon' mechanism.
The introduction of 'npm run X' has also raised some comments in the
past regarding cross-platform support. These is IMHO not bikeshedding,
it's about being careful in adding extra complexity or going in a
wrong direction.

There are other examples of changes that go through quickly and
without a lot of problem. Examples are the changes regarding 'issue
references' (issue_pat and friends), the refactoring of the VCS test
classes, and the recent update to V2 reCaptcha.

Regarding clean commits: it is an explicit part of the project
culture. From the docs/contributing.rst file:
"We care about quality and review and keeping a clean repository history."

You have made clear in the past that you think this is often a waste
of time, but I disagree (and I'm pretty sure Mads does too). A clean
repository history is invaluable both during review, as during future
changes, to understand why something was done.
It would save time and frustration from all people involved if all
contributors take along this principle from the start when designing
and ordering commits. If you think from the start how your commit path
will be, the lost time is minimal. And when these commits are small
and well documented in the commit message, then review will be much
easier.
I'm glad that you split up the one big remaining bootstrap commit 'in
small parts', like we asked. Honestly, I think it was the only way
forward, and thanks to your cooperation we landed already a big part
of it.

>
> What troubles me the most about this, is the lag of communication. It
> sometimes takes weeks or even month to get any kind of feedback.
> I understand that people are busy, but as a leader of a project like this
> you should at least drop a quick sorry note and say when you will be able to
> look into the thing. Or delegate!

I agree that this is a weak point at the moment, and that we should
improve here.

>
> And I'm not the only one who has this problem. Our bitbucket is full of old
> PRs that went nowhere. Take the ssh PR for example. That one is 3.5 years
> old! I believe most of those people just gave up.

It's true that we need to pick up these old PRs or reject them. This
was agreed upon already a long time ago.
But the total bandwidth is limited, number of contributors is small,
so you can only do one thing at a time.
In the release 'roadmap' I proposed earlier [1] I suggested to finish
the bootstrap changes and then make a release 0.9, and shortly after
1.0.
At that point, I think we should try to reduce the open backlog. But
it makes no sense in trying to clean up the old backlog if the current
active PRs like bootstrap are not yet finished. It would only disperse
focus of all people involve, and slow down the bootstrap PR.

This is also the reason why I'm currently not actively looking at your
other PRs (like 'various changes' and 'hooks'): it would move away
focus from what we said is first priority. Just like you, I would like
to get over bootstrap as soon as possible so we can move on.

>
> I really believed this project had potential. But all my attempts to improve
> the communications or the projects organisation have been ignored. And my
> PRs were treated purely and very slow.
>
> What needs to change:
> - Stop pondering if some small change should be its own changeset
> This wastes A LOT of time. The quality of the code needs to have a higher
> priority then the quality of the changeset history!

Like I said above, I don't agree on this one. It's perfectly 

Re: This Project has no future!

[Long Vu]

On Mon, Apr 9, 2018 at 2:08 PM, Dominik Ruf  wrote:
> Hi all,
>
> I was in denial in the past years. But it is time to face the facts. This
> project isn't going anywhere.

I am sad to hear this.  Kallithea is about the only *completely open
source* all in one repo management, code review tool that also support
Mercurial.

Mercurial needs more tooling support.  Git is more popular not because
Git itself is easier to use or have more features or can enable more
workflows (Mercurial Evolve extension beat Git lightweight branching
and server-side history rewriting by a long shot).

Git is simply more popular because of the tooling support.  Tooling
support is something Kallithea brings to the table.

> About a year ago I already expressed my worries, but next to nothing has
> changed since. There are still pull requests that are multiple years old.
>

I am guilty of this as well.  I have 1 or 2 PR that has been sitting
there for over a year, or almost 2 years (ouch), simply because I have
not had time to polish them for re-submission.

> For example, my bootstrap PR is still not pulled completely. There is still
> a discussion about whether (and how) we should use minification and source
> maps.
> These are technologies that practically every web application in the world
> are using. So this should be a no-brainer. And yet, after more then 2 years
> we discuss if adding the source map flag should be in a separat changeset.
> Seriously guys, this could be in the dictionary as the very definition of
> bikeshedding.
>
> What troubles me the most about this, is the lag of communication. It
> sometimes takes weeks or even month to get any kind of feedback.
> I understand that people are busy, but as a leader of a project like this
> you should at least drop a quick sorry note and say when you will be able to
> look into the thing. Or delegate!
>
> And I'm not the only one who has this problem. Our bitbucket is full of old
> PRs that went nowhere. Take the ssh PR for example. That one is 3.5 years
> old! I believe most of those people just gave up.
>
> I really believed this project had potential. But all my attempts to improve
> the communications or the projects organisation have been ignored. And my
> PRs were treated purely and very slow.
>
> What needs to change:
> - Stop pondering if some small change should be its own changeset
> This wastes A LOT of time. The quality of the code needs to have a higher
> priority then the quality of the changeset history!

Just my 2 cents here, using Mercurial Evolve, it's super easy to
change changeset history.

I agree that changeset history is not a hard requirement but a very
good nice to have if time allows.  Make the job of the reviewer easier
and then the review can review more and give faster feedback.

Long term, it can help training new developper as well.  When working
on new area of the code, I tend to annotate, dig the history the few
files I think I will need to modify, just to see what kind of past
features, bug fixes also touched these files so I know what kind of
impact my change will induce and plan testing accordingly.  Too big a
past commit and I will just get that something in the past needed this
area of the code but not precisely why so it's harder to understand
the implicit dependencies.

> - Stop making the 'better', the enemy of the 'good'.
> If somebody comes up with a better solution in the future, great, but up
> until then settle with the good solution you have now.

Agree with that one.

> - Start using JIRA to manage and prioritize the open issues, PRs and other
> tasks.

Doesn't necessarily have to be JIRA but any kind of project management
tool is good.  I remember someone on this list was considering redmine
or another newer tool with lots of potential.  Completely open-source
tool is preferred of course but maintenance and support effort have to
be considered.

> This projects simply needs to get organized.
> - Promote riot.io as communication tool for more direct engagement.
> I mentioned before, that I think mailing lists and IRC are anachronistic
> tools. And they are not ideal to engage with people.
> In the mean time, Andrew set up the matrix.org bridge, which allows to use
> apps like riot.io to chat with our IRC channel. riot.io allows to always
> stay online and search in the conversation. But AFAIK practically nobody
> knows about it.

This one is big.  I've been using Riot for more than a year and I can
vouch for it.  It basically replace Slack, Skype, Viber ... all those
closed and proprietary walled garden.  It is completely open source,
federated and uses an open protocol Matrix so any other app can
implement support if desired.

Group chat is first class citizen.  Group video conferencing works
very well.  It has desktop (Linux, Windows, Mac), web (no install
required for the occasional user, group video conferencing works very
well in the web as well), Android, iPhone.

If you want privacy, the same