community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Rethinking email (was Re: A plead from a chair with an overloaded mailbox.)
Date Fri, 20 Oct 2017 08:17:19 GMT
(Moving to dev@community)

> On Oct 20, 2017, at 10:56 AM, Harbs <harbs@in-tools.com> wrote:
> 
> I’m wondering if it makes sense to take a step back and rethink email and communication.
This feels like part of a bigger challenge.
> 
> Apache has gotten big enough that email overload is becoming (became?) an issue. The
market at large has been making efforts to solve the email overload issue with varying degrees
of success. Slack come to mind as an example (with mixed success).
> 
> To be clear, I’m NOT suggesting that we should replace email with something like Slack,
but I do think it might be beneficial to examine some of the techniques out there to make
communication more manageable.
> 
> There’s an additional element to the problem as I see it: A certain amount of chit-chat
is important for maintaining a sense of community. However when the chit-chat becomes overwhelming
it backfires.
> 
> Some concepts which might be worth exploring:
> 
> 1. Priority — If there was some way to subscribe to emails about a certain priority
level, it could be much easier to only get what’s appropriate and/or filter out the unimportant
items.
> 2. Better threading — If there was a way to not see (by default) chit-chat threads
that one does not participate in, that could enable side discussions while not being overwhelming.
> 3. Topic tags / subtopics — I find the Slack channels to be very helpful. I generally
subscribe to any channels which I’m slightly interested in, but being able to instantly
see which channels have discussions allows me to decide whether I have the time or interest
at the moment to read it.
> 
> Now, I have no idea how to go about implementing any of these ideas, but it feels like
that in this day and age, these should be solvable problems.
> 
> Some thoughts on possible directions:
> - better use of email features. Email headers can have priority set. How can we take
advantage of this?
> - Finer-grained subscriptions. Right now it’s binary. You are either subscribed or
not subscribed to a list. (Yes. I know there’s digests, but those don’t really count.)
There’s no way to subscribe to lists based on content or headers, etc. (How) can this be
improved?
> - Would it make sense to create an “Apache Communication App” tailor made to the
needs of Apache communication? We have some of the best minds in software architecture here,
and it feels like if anyone can do this, it should be us… ;-) Besides  having the potential
of solving these issues and more, it could be useful for alerting folks about and collaborating
on time-critical issues (such as the recent media responses about Struts).
> 
> Thoughts?
> 
> Harbs
> 
>> On Oct 19, 2017, at 11:19 PM, jan iversen <jancasacondor@gmail.com <mailto:jancasacondor@gmail.com>>
wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>> On 19 Oct 2017, at 21:17, Kevin Meyer <kevin@kmz.co.za <mailto:kevin@kmz.co.za>>
wrote:
>> 
>>> Call me grumpy but my pet peeve are the numerous *personal responses* to a board
member that are cc'd to board@ whenever a board member announces when they go on vacation,
has a personal issue, etc. 
>>> Communication is great, but "have fun, get well and condolences" *replies* don't
need to go 200+ PMC chair mailboxes! 
>> 
>> Count me as grumpy as well :-)
>> 
>> and filtering those are quite a challenge.
>> 
>> rgds
>> jan i
>>> 
>>> Kevin
>>> 
>>> On 19 October 2017 18:24:10 CEST, Tom <tom@falkensweb.com <mailto:tom@falkensweb.com>>
wrote:
>>> +1 
>>> As my first month on this list, it's a torrent. 
>>> It's just encouraging me to divert it all out of my inbox, so guarantees I'll
miss the important things because I'm drowned in robot generated near identical mails about
a couple of hundred projects. 
>>> 
>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message