cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: [DISCUSS] Email etiquette CC or not CC
Date Thu, 17 Jan 2013 00:43:07 GMT
On Wed, Jan 16, 2013 at 4:04 PM, Joe Brockmeier <jzb@zonker.net> wrote:
> On Wed, Jan 16, 2013, at 05:43 PM, Edison Su wrote:
>> Hi all,
>>      I am struggling to read all the emails on dev list everyday, it's
>>      just so many emails. Is it possible, that enable/allow/encourage us
>>      CC  to somebody if you think the topic he/she should take a look at?
>>      I think it will save both of us a lot of time.
>
> I've softened my position on this somewhat based on the conversation
> today in IRC, but I still have misgivings about adopting a "CC someone
> if they need to look at something."
>
> 1) Committers *should read the -dev list*. I understand that it's high
> volume, and I don't expect people to read every email thoroughly on the
> off chance that there's a mention of an issue that involves them.
> There's a lot to be said for judicious use of email filters,  threading
> mail clients, and good mail hygiene of using descriptive subjects, and
> so forth.
>
> I'm concerned that if we get in the practice of CC'ing people, we'll
> start having (more of) an issue with people expecting to be CC'ed and
> invited into a conversation. That means we lose their participation in
> threads that may not be specifically their issue, but they might have
> something worthwhile to contribute or have concerns that should be
> voiced.

Committers still should read the -dev lists. But it's easy to keep
pace when community is small, but it's unable to scale when community
getting bigger and bigger.

Using CC is the most scalable way to deal with community AFAIK, and it
works well in LKML, xen-devel, etc. And they are all working well. I
don't think CloudStack would be an exception. From my experiences, CC
is not something people would expect, it's something that ensure it
caught the right people's attention, and keep the right people in the
thread.

And there is the best thing about CC: Once you got CCed, you're in the
thread, unless you asked for removing CC explicitly. This enable you
to keep track the thread all the way down.

>
> 2) CC'ing people means you have to know who should take a look at
> something. A new person to -dev who has a question or issue may not know
> that they should CC someone.

They don't need to. I am pretty sure the post to lkml or xen-devel
without CC anyone would still caught proper attention.

But CC can keep you tracking the thread, which is best thing in the community.
>
> If we're going to get into the practice of CC'ing people, I'd like to
> see every committer have a page on the wiki that gives some insight into
> what area(s) of CloudStack they can or should be CC'ed on. (There's no
> reason non-committers cannot do the same, of course. But at a bare
> minimum, we should do this with folks who have commit privileges.)

I think we can have that kind of wiki page, though the normal process
I experienced is:

1. One guy send a mail to the list, without CC anyone.
2a. Someone jumped in, mostly the related committer.
2b. Or some guy said, hi, you should talk with that guy, and CC him.
3. Thread go on and on. There would be discussion or patch follow on
at other threads later, and the original poster would like to keep the
same group of guys in the following threads as well - he knows who to
CC now.

> 3) Personally, I *don't* want to be CC'ed on messages sent to the list.
> I already subscribe to the list and try to keep up with the mail. Being
> CC'ed just means that I wind up seeing the message twice - which
> exacerbates the problem of having too much email to filter through in
> the first place.

This some how relate with the mail client. You can copy all mail sent
CC/TO you in one folder, and if one mail sent to the mailing list
copied you, set a rule to mark the same mail in the mailing list
folder as read, but kept the one in your copy as unread. I think it's
more likely a technically issue.

--Sheng
>
> All that said - we need to find solutions that work for this community,
> and I'm willing to give this a try if the consensus is that it will
> work.
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/

Mime
View raw message