>
>
>
> 1. make sure foundation itself provides an MVP for at least two
> styles of communication channels ("topic grouped channels"
> and "instant messaging channels"). We've got email and perhaps
> Matrix could be a good enough answer to the 2nd requirement.
>
That would be great. My slack relationship is a bit of love-hate and
especially when recently they enabled it for a month in "full" version
and then started to annoy us with "do you really want to lose all that
- do pay" was a bit crossing the line (and we can expect more of it).
Having a good "modern" replacement "blessed" by the ASF would
be fantastic. Matrix looks cool and ASF promoting free and distributed
and modern communication tool for that seems like a great idea.
2. The best we can do on everything else is simply collect a sort
> of FAQ advising our communities on places they should consider
> monitoring/engaging so that they "go where [users] are" to your
> point.
Anything else I am missing?
>
>
I thought a bit about this and I think I realized something.
I think what I miss is something in-between those two emails/async-
at least for some of the communities and for some parts (see below)
I think email is great to do really "official" communication and
particularly
information that relates to the community. Everything that is related to
the community -
is all fine to be discussed on the mailing list (establishing processes and
communication rules, deciding on project policies etc).
And if we treat it this way, this is good and I never saw any problem
with it.
But I think other media (particularly GitHub Discussions and GitHub
Issues) **might** be better for some communities to make even
important decisions about the *code* not about the community.
I think we are really at the place where many of the projects require
anywayw GitHub account, otherwise you can neither discuss nor change
anything related to the code. And I think we should embrace the fact
that GitHub tools are simply better suited to discuss any code related
stuff and even make decisions there. This already happens for small
things (basically in every PR) and this is extremely blurry when the
decision is big-enough to bring it to the devlist. The motto "if it did
not happen on the devlist - did not happen" is not even mentioned
anywhere in the official Airflow docs (or I could not find it) but we
keep on hearing (and I was myself saying that multiple times).
If somebody asks me now about a new feature or "Concept" change
in the code - I have no way currently to explain when the feature
is "big enough" to be discussed on the devlist or whether it is
enough to get it approved in PR or issue.
"Community over code" is actually there in Airflow official docs and main
motto.
Maybe we should simply (as the official approach of the ASF
make it a totally viable possibility for the projects to use those:
* when you discuss about community and the way it works "if it did not
happen
on the devlist - it did not happen"
* but when you discuss code - "if it did not happen on the <choose your
medium here that fits our criteria> it did not happen".
I think I would be perfectly fine with that. That is maybe not perfectly
black-
whilte criteria (code and community discussions have some overlap) but it
is much "clearer" to me than any other criteria I could apply even now
to what we do.
WDYT?
J.
