Should “private” emails be CCed to public mailing lists? 
Suppose I email Jon about the register allocator in the DragonMonkey branch . I’ll just email him directly, and that discussion won’t be open. This happens dozens of times a day—one colleague emails another asking a question or proposing a solution , and nobody else gets to see it . We should fix this and open that stuff up.
The closest thing that currently exists is that I could CC the relevant mailing list. I don’t want to do that. When I mail a list like dev-platform, I consume the time of hundreds of people who read that list. Often, I write and rewrite an email to ensure clarity  before I send it. It’s important to explain context, history, project roles and aims, and all the other things people need to understand for my email to make sense . Actually, most of the time, I end up not sending that mail.
So we need something which isn’t so expensive. In the forum discussion, I suggested a CC-list - an address that you CC on emails that should be open, but which you don’t want to send to the relevant mailing list. Interested parties following the CC-list can then read the conversation, skim it, ignore it, or participate in it.
So if I want to understand how that thing works, and I need to ask Jon about it, I would send Jon an email as normal, and throw in the CC for good luck. I’d ignore clarity, wouldn’t address it to a wider audience, or do anything any different than normal. Just “Dear Jon”, and be done with it .
So if we build it, will they come? I don’t really know. I see lots of problems. Maybe the way is to just try it.
One CC-list for the whole project is too few. If you work in marketing, you don’t want to lurk on the engineer list, no more than I want to lurk on Metrics or Graphics or Jetpack . So I would say that if you currently have a niche list, the CC-list should just be an extension of that .
You know what would rock? If all mail to email@example.com was automatically public, and anyone who wanted to send private mail (my boss, HR, legal, etc) would send it to firstname.lastname@example.org. Default to open! I think that might actually be too hard to make work, but it would be too cool. I’d definitely support creating a email@example.com account though .
 An employee-only link? I know right? A discussion about openness on the one part of the entire Mozilla infrastructure which isn’t open! But he, I, and pretty much every Mozillian (employee or not) wants everything we do at Mozilla to be open, so please forgive us when we occasionally fail at it.
 Neither Jon nor DragonMonkey exist.
 Note that this isn’t strictly an employee thing, maybe non-employee core-contributors are talking.
 Note that this is not the same problem as when we want to quietly do some design work on something before announcing it more widely. That’s a different thing.
 At least, I should.
 Mostly, I don’t want people to think I’m an idiot.
 Why is this cheap when sending it to dev-platform isn’t? By construction. If we define the list to be one which should be skimmed at best, then we treat it that way regardless of how it’s used in practice.
 Fine people though they are, I don’t need to read their semi-private email.
 We can’t just repurpose the original niche list either, since that’s not the contract the subscribers agreed to, and also it would drown out other email.
Steve Fink: pbiggar++
I like it. Well, ok, I like the pbiggar-public incarnation of the idea.
The problem with pbiggar at mozilla.com being public is that you are deciding on the sender’s behalf that the message should be public. Which isn’t nice. At all. Especially for people who haven’t emailed you before and aren’t aware yet.
One concern would be requiring correspondents to keep track of one more email address for you. That’s unnecessary for pbiggar-public at mozilla.com or pbiggar+public at mozilla.com or (I think I prefer this) pbiggar at public.mozilla.com. But a lot of people use other email addresses. I have both sfink at mozilla.com and sphink at gmail.com, for example, and I use both for different segments of my Mozilla-related mail. I also use Thunderbird as a mail filter on my gmail account (it sorta works), so I could set it up to work (well, public.gmail.com won’t), but I think this would need a common mechanism to work.
Just handling mozilla.com addresses would be enough for this to be useful, I think. There could be a fallback CC for other addresses.
One missing piece – if I send to pbiggar-public, which CC list does it go to? Or more to the point, if I send to bz-public or damons-public, where does it go? Is there a mapping of user -> set of CC lists?
It might be useful to also post initial thread subject lines to the relevant IRC channel as well. Or a CC version of the IRC channel.
And we’d have to establish conventions about when it’s ok for a third-party observer to start participating in the conversation – read-only access to these sorts of conversations is one thing, but if I wouldn’t use it if people felt free to start chipping in and starting flamewars on them.
I’d be ok with a policy where you never interject into someone else’s conversation, but you’re always free to start a new thread quoting anything in that conversation.
(Side note: I used “ at “ everywhere in this post in place of the at-sign not for spam protection, but because the commenting software is doing something truly horrible and evil where it tries to make special links or something when it sees an at sign. And they’re hard to get rid of. Even if you’re nowhere near, the magic-at handler seems to take control of the enter key. Kill kill die die die.)
Karl: In W3C reality, it is called the *-archive mailing-list. It is very practical. It helps also with communications on the outside, when you want to keep a Web record with a permanent URI for future references about a mail you just sent.
you could have indeed thematic archives, or a a general archive mailing-list, I would recommend two at least, one which is “private” and related to the social contract of the group and one which is open to the public when it is about public communications.