On Wed, Jan 16, 2013 at 4:04 PM, Joe Brockmeier <j...@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 > j...@zonker.net > Twitter: @jzb > http://www.dissociatedpress.net/
