Great discussion!
Kaxil:
One of the very recent examples was of recent AIP discussions about
> Reschedule Operators (or Async Operators). I missed the "group creation" on
> Slack for that SIG (Special Interest Group) as Slack already has 100s if
> not more messages daily and hence also missed the informal meeting which I
> (and other users like me) would have loved to be a part of.
>
Indeed that's a very good example where things can get missing-in-action.
When we get too used to quick communication on slack - these things happen.
And it happens even to people who are used to mail communication, so I
understand it might be a "natural" thing to do by someone whose
primary/first communication media is slack.
> But it is definitely not a drop-in replacement for the dev-list where there
> are talks about architectural design, Roadmap discussion going on. You can
> argue that we could use a Slack
> channel to do that, however, once an email is sent to the dev list it is
> public and for everyone to see, Slack is a messaging platform, hence users
> can delete the messages for whatever reason.
>
Yes. I think the last part is very important. I think this requirement
"what's being said is being said forever" is super important and kind of
contradicts with one of the earlier basic problems with email mentioned by
Anton ("you can't edit your previous message"). And I think it's an
important property of official communication media for the project. It
means that you have to be really conscious when writing your message, you
cannot modify the original wording and spelling mistakes. That makes it
simply slower and more deliberate.
I can add more documentation in Contributing.rst to explain which medium
> should be used.
>
We should indeed! Thank Kaxil! I am happy to cooperate on a PR on that and
add what I think is relevant. I also added (for now I left TODO) page in
the "First time Contributor's workshop" presentation template at
https://cwiki.apache.org/confluence/display/AIRFLOW/First+time+contributor%27s+workshop
and
I will bring the content of what we agree in CONTRIBUTING.rst to the
presentation and workshop that we are going to have. I hope to be able to
run at least 4 or 5 such workshops in the first half of 2020 and I think it
is important to mention result of this discussion to the
first-time-contributors. Also that should include some of the "how to use
email" because I think people simply do not know that they can use email to
achieve some of the things Anton mentioned quite easily using email
interface (see below).
Anton:
> > That was me, got mixed my mail accounts.
> > Regarding problem 4: probably we should explain to newcomers not only how
> > to use dev lists, but also why we use it. Dev list was just a weird
> legacy
> > solution until I've heard about Apache requirements and SE indexing .
>
Absolutely (and see above!)/ I think this is the most important result of
the discussion so far - that we need to explain more why devlist is so
important and that it's not just a legacy. Maybe we should also mention the
Pony mail as a tool that you can use to make it easier (even if just a bit).
> > Although sometimes
> > you'd
> > > like to make it quick (e.g. hotfixing that requires >1 ppl).
> Slack/Gitter
> > > provides you an opportunity for both quick/slow communication. Email is
> > > very bad for quick replies. That limitation is the thing I'd like to
> get
> > > rid of.
Slack is better for quick replies. And we already have it :)
I think we can explain that in the "communication" section of
CONTRIBUTING.rst about when to use which media.
> > > a) I can't quote particular sentence to address it
Actually - you can. This is what I am doing right now (using Gmail but I
checked it works with Pony as well).
I think we should make it part of our workshop to teach people a bit how to
use emails for that efficiently. In devlist responses, the best thing you
can do is to hit reply, and navigate down the response, delete what is not
relevant leave only the parts you want to respond to and interleave your
answers with the original quotes. I think it works really, really well once
you learn that this is the "email way". Most of good mailers understand
that - for example in Gmail it uses different colours for the quotes and
you see nicely what part of the message you are responding to. You can even
respond to several people in the same message (that's what I am doing now!)
> > b) There is no way of structuring your text (like bulleting,
> > underscoring,
> > > indentation, etc). Yes, I know I can use it in the Gmail web client,
> but
> > It
> > > is way harder to navigate there.
>
There are some markdown standards that we are pretty used to and I think it
works pretty well when you have a good mailer to provide both HTML/TXT
version of your mail. However, maybe that's something we could contribute
to PonyMail as well - just add some basic formatting/structure helpers to
format the message?.
Bullet list example:
* one
* two
* three
> > > c) No threads. Every discussion tends to split into different branches,
> > so
> > > it is nice to be able to join one of the threads ignoring the whole
> > > discussion (or vice-versa).
>
I think this actually threading is much worse for Slack etc. than it is for
emails. It's common to do "thread hijacking" in Slack as well as in email
and it's a matter of people not the tool. I'd actually argue it's much
easier to manage threads in email/devlist than it is in slack. The threads
in email are even better because they are named (by subject). There is
nothing wrong with replying to message and changing the subject - this will
create a new thread. It's even better if you can combine it with quoting as
mentioned above. Because you can delete irrelevant parts and only quote the
parts that you want to refer to from the original thread.
> > > d) Reply window just holds half of my screen. I have to close it to
> > reread
> > > some points in the discussion.
>
Typically what I do is I go down the message and delete irrelevant parts
and respond to those that are important. Then you can see what you are
responding to immediately next to your response. Of course there is often
an earlier message you want to refer to, but you can always open another
browser window with it. Not perfect. I know. But maybe again - that's an
opportunity to contribute and make PonyMail interface a bit better :).
> > > e) A lot of niche things that I get used to (like polls, images, etc).
> > > They're not that crucial but make communication easier.
And emoticons of course :). I like those too. There email interface is
clearly behind. But we still can use slack for those, leaving devlist for a
bit more "formal" communication. You can still interleave some of the stuff
with your message though. A little bit more involved but if you really want
it can work (for some people at least)
[image: source.gif]
> > > f) I still have a cluttered inbox, hence all the discussions arrive
> > there.
> > > Yes, I can create smart filters, but it still needs some effort.
> > >
>
Yes. It does. But I think it's even worse in slack (especially if we are
really for the "deliberate, slow, well thought discussion". In email at
least you have named threads to follow.
> > > 3. Yes, mobile device is a problem. Mailing lists on mobile are still
> > just
> > > Gmail client which is horrible for that kind of discussion.
>
I am not sure why it's such horrible :). I actually respond to many emails
from the phone using gmail app and I find it pretty OK (providing that I
use the quoting/deleting pattern I mentioned above).
> > 4. And now my biggest concern: for the majority of users joining to
> mail
> > > list sounds like an invite to MySpace. It is easier to skip the
> community
> > > then make an effort into understanding how devlists do work. I think
> the
> > > main problem is not the struggle of existing users but the number of
> > > developers who skipped conversation being afraid of the unfamiliar
> > > messaging tool.
>
I understand that point, but I think what we can do is to educate people
(on slack/workshops/CONTRIBUTING) and tell them why it is important to use
devlist. Maybe we should also create a separate channel on slack
(#how-to-communicate) next to the existing (#how-to-pr) and provide people
with some useful help and mentoring about communicating in the community? I
am happy to be part of this :).
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
