Discussion: Mailing Lists

[jasnell]

What specific mailing lists do we need? Which mailing lists are already established under @nodejs.org and @iojs.org? What is our migration strategy for these? What new lists need to be created? e.g. members@nodejs.org, tsc@nodejs.org, collaborators@nodejs.org, etc

[mikeal]

We have no prior email lists for iojs.org, everything has been done in GitHub repos instead.

I wonder if we can get some kind of export of this info from Google Apps for nodejs.org?

[rvagg]

Mailing lists are kind of risky in that they exclude others from the discussion going on. In practice we've only had need to use private email discussions for:

• security things
• political-ish things, mainly re the relationship with joyent/node and the foundation and contentious things that may cause drama if they were opened up prematurely

Hopefully we'll have a lot less need for the latter, leaving only security as a real need for private discussion. I can see a use for a security@ list, then escalating discussion to a tsc@ list and hopefully being able to broaden it to collaborators@. However, simply the existence of these lists creates the risk that people will actually use them for things that should be done in the open, so I'm torn!

[mikeal]

We also use private email threads for the participation link/info for TSC meetings. I think security@ and tsc@ both make a lot of sense.

There's also a list called membership@ that we use for sending signed membership agreements and inquiring about information about corporate membership in the foundation. If we continue using them we'll probably need a board@ list for the same participation link/info for the board meetings like we have for the TSC meetings.

In general I'd like to think of these more like email groups than "mailing lists" (yes, I know that in terms of technology these are essentially identical). GitHub repos work significantly better for the job we used to hire mailing lists to do so except in the few cases where we need privacy (security issues, private information, etc).

Now that we have a non-profit we can get our GitHub org marked as free and we can start using private repos and private teams (this is a new GH feature). This may be a better way to create private threads and share the private info we used would have previously shared on mailing lists. The problem with mailing lists is that when new people get added it's fairly difficult to see the history and to get onboarded. With a private repo we could stick onboarding information in the README and the issue history would be available.

[guyellis]

Thanks for that info about that new GitHub feature @mikeal - wouldn't that negate the necessity for security@ and tsc@ for the reasons you stated? Or is that what you're saying and I misunderstood where your comments went?

[mikeal]

Any time we need someone outside the group to be able to contact one of these groups we'll still need an email address. security@ is certainly in that column, not sure about tsc@ though now that I think about it.