To repeat what I have written elsewhere on this topic in the past:
Project communication channels should be:
- Public. The decision making process should be open and visible to
everyone. It should also be easy for people to find.
- Searchable. So anyone can look-up past discussions.
- Asynchronous. To enable participation from a globally distributed
community.
- ASF owned archive. So we always have access to past discussions.
- Low overhead. Community members may not have access to powerful PCs
or high-speed and/or reliable internet. The lower the overhead of a
communication channel, the greater the potential for participation.
- Usable off-line. Helps those with poor / intermittent / expensive
internet access and those who are off-line for other reasons (e.g.
traveling)
I wonder if something like matrix[1] could be a way to enable people to
communicate via their platform of choice whilst retaining our archived
mailing lists as the canonical view.
Mark
[1] https://matrix.org/
On 16/02/2022 16:15, Jarek Potiuk wrote:
For me (and I think I speak for a number of Airflow people) slack is great
to keep casual discussions, help users with troubleshooting or do some
brainstorming, and also to make announcements and ask people for opinions.
But it's non-public by default and not easy to find stuff.
For most of the "what happens in the project" however this is the kind of
"short memory" storage. When I remember something happened in slack I
rarely care to search for it (and when I do, the result is usually poor).
Also because slack has the limits for free versions and is terribly
expensive for big communities (though we have a read-only version of all
archives - via a web app developed by one of our team members, so we keep
and exose publicly all "public" conversation actually).
We also tend to not make decisions there, but similarly as others
mentioned, bring discussion to the devlist (often linking to the slack
conversation though) and decide there.
However there is one more interesting medium where more "substantial" and
really interesting discussions happen - Github Discussions.
https://github.com/apache/airflow/discussions (and GitHub Issues to some
extent) - we use it for multiple purposes (including converting
troubleshooting issues to discussions.
More often than not, discussions about "important features" are more
interesting and more people are engaged there and they will spend
their time and energy there. Also because (contrary to having a GitHub
account) not everyone interested reads and subscribes mailing lists.
I personally believe there are a number of people who are never going to
use a mailing list because it is "ancient" and "intimidating" for them -
and some people literally and loudly despise it. The inability to mention
people and issues, embed video, emoticons (yeah), links and images easily.
But I think there is one important intimidating factor of the mailing list:
the inability to correct your typos and mistakes and updating your
statements after you sent it, puts many people off.
BTW. Github Discussion and issues also track and expose history of changes
so you cannot "remove" what you wrote - it is still there, but less easily
accessible - this pretty much guarantees that you will not want to use it
to modify your statement completely - but you can add corrections. And when
you subscribe to changes in the project via (yes!) email - you can still
see original "typoed" message there.
To be perfectly honest, sometimes when I write "Please raise it as a
discussion in the devlist - here is the link to how to subscribe" in many
cases this feels like a "/dev/null" redirection). I did it many times and I
recall maybe once or twice when a new user with a good idea (but one that
was more than just a PR) actually started a thread in the devlist. Usually
discussions like that simply disappear.
I think GitHub Discussion/Issues fulfills a lot of the criteria of what was
important for mailing lists: public, searchable, you can keep archives (via
emails at the least). And it is way more approachable and modern than
mailing lists.
J.
On Wed, Feb 16, 2022 at 2:56 PM Gilles Sadowski <gillese...@gmail.com>
wrote:
Le mer. 16 févr. 2022 à 14:16, Gary Gregory <garydgreg...@gmail.com> a
écrit :
My assumption using Slack is that it is a convenience
Provided that everyone has been informed that a discussion
is going to take place there.
What about the "asynchronicity" tenet of the "Apache Way"?
but that decisions
MUST be reflected on a mailing list.
IIUC, it is not allowed that a decision _actually_ take place
elsewhere (as per "If it did not happen on the ML, then it did
not happen.").
Regards,
Gilles
Gary
On Wed, Feb 16, 2022, 08:13 Trevor Grant <trevor.d.gr...@gmail.com>
wrote:
I shared in Comdev channel on ASF Slack that on the mahout slack we
have a
convention that when we get to something that should be memorialized
someone says, "This should really be reflected back to the list". And
whoever says that has implicitly called "not it" for having to reflect
it
back- This motivates everyone to be the first to say "This should go
back
to the list". In the rare cases where no one says it- the original
author
reflects back to the list- as is the case with this email and the
comdev
list.
On Wed, Feb 16, 2022 at 7:08 AM Gary Gregory <garydgreg...@gmail.com>
wrote:
Slack chat and video helped us tremendously on the Log4j team
especially
since Log4Shell.
Gary
On Wed, Feb 16, 2022, 07:50 Roman Shaposhnik <r...@apache.org> wrote:
Hi!
while the classical ASF communication culture is pretty squarely
centered around mailing lists it has become apparent in recent
years that some of our communities (especially younger ones)
prefer using alternative channels of communication. The range
is pretty wide from Slack to Telegram and WeChat (and I have
even heard of an occasional TikTok use ;-)).
The question that originated from one of the board meetings and
the one that I'd like to pose for this forum is basically: what's
our
collective advice to these communities on these alternative (and
when I say alternative I really mean anything but a mailing list)
communication channels?
Personally I don't think denying them is a viable strategy, but I'd
like to open up this discussion and see what others think.
So... let's at least start with folks sharing their experience with
these alternative communication channels: the good, the bad
and the ugly.
Personally, I don't think I have much to share -- I'm still very
much a mailing list guy when it comes to ASF.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
