Re: Thoughts on alternative communication channels for our communities

[Gilles Sadowski <gi...@gmail.com>]

Le lun. 28 févr. 2022 à 23:01, Tomasz Urbaszek <tu...@apache.org> a écrit :
>
> I'm reading this discussion from the beginning (thanks to ML). I can be
> mistaken but there are two issues:
>
> 1. A community communication channel. A place where users can interact,
> discuss and seek help. This should be a place for users and the community
> should use whatever serves best.
> 2. Decision making channel. In this case we seek for an ability to archive
> and search (dev@ mailing list) but we also seek engagement from wider
> community (not offered by dev@ list).

So IIUC, we already have everything (because I don't agree with the
"not offered by list" statement). :-}
People can chat informally (towards achieving any set task) anywhere.
But decisions must be put to discussion and made on the appropriate
mailing list (which can then be mirrored to other channels), if only to
assume "lazy" consensus.

>
> In case of 1 we have poor chance to unify things (for example Slack vs
> WeChat).

And that might be why the "old" ML is still there.  New tools come...
and go.

> In case of 2 we can take advantage of the fact that every project
> now is on Github. For example what Apache Superset is doing looks
> impressive: https://github.com/apache/superset/projects/7 They still do the
> voting on mailing list
> https://lists.apache.org/thread/t2yc69rm60o7mlrp114r9rmdm96k7cwg but we may
> consider using some bots for handling this integration (possibly in both
> directions).
>
> Issues and discussions can be deleted. In this case we can consider using
> pull requests that support the same (or at least similar) threading
> functionality as issues/discussions. We have nice tool for tracking
> changes, reviewing and suggesting. This is more similar to what Kubernetes
> is doing for theirs "enchantment proposals":
> https://github.com/kubernetes/enhancements/pull/1353.

I'm not sure what that conversation is meant to illustrate; IMHO
it's full of visual noise without any significant advantage over a
discussion thread on a ML (that can contain URLs).
[Of course it's fine for GH users to use GH tools in order to work
on GH repositories (as per your point 1 above).]

>
> This is just idea but Github is common to every project. It's something we
> all have, so why not start there?

Because, IMO, a GH account should not be a requirement in order
to work on an ASF project.
Until the ASF decides that it stops supporting non-GH contributors,
a certain confusion is entertained by assuming that everyone is, or
should be, there.

> In fact maybe we can take some lessons from "newer" communities like CNCF
> projects that are no longer ML centric?

I see that they still use them:
  https://lists.cncf.io/g/main/subgroups
[I didn't dig further to check whether the various communication channels
are integrated.  Again: If integration (with the MLs) would work at the ASF,
I'd be fine: My issue is with shutting ML-people out.]

Best regards,
Gilles

>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org