More communication channels with the teams

[japaric]

We now have 5 brand new teams 🎉. That's awesome but I think we need to make it clearer how someone can contact the teams.

Ideas:

• Add your IRC handle to the README. (Easy)
• Add your discord handle to the README. (Easy)
• Set up e-mail aliases for each team (e.g. [email protected]). This private communication channel is required to receive reports regarding moderation and violations of the code of conduct. (Not sure what would be needed to set up those)

A perhaps orthogonal question is how the team will notify the stakeholders (e.g. users of the Cortex-M crates) when their input is required to make decisions on breaking changes and other RFCs (e.g. rust-embedded/cortex-m#82)? I can't think of a good solution for this. I try to cc stakeholders when I open an RFC but I would only reach out to more or less active contributors (also, my memory is not perfect).

The rust-lang org tackles this problems in the following ways: they have a dedicated RFC repository which you can subscribe to (IMO, traffic is too high and the topics so varied that this will overwhelm most people); they post new RFCs and which RFCs are entering FCP in their weekly newsletter (their newsletter has a much larger audience than ours so this may not be as effective; also our newsletter has a biweekly cadence).

Thoughts?

cc @rust-embedded/all

[ryankurte]

Maybe we could have join links for the discord and IRC channels in our documentation too?

I see to always end up using mailgun with a forwarding rule to setup / manage email aliases, it's far from elegant, but works if noone has a better solution (and could perhaps be a step towards email subscription to the newsletter too).

WRT stakeholders, it's probably not going to help everyone, but perhaps we could we also render out the RFCs as a static site w/ RSS feed (as well as posting them in the newsletter)?
Then it's pretty easy to automate into whatever tooling / chat clients / anything else people are using, and doesn't require reading the newsletter to keep up / isn't effected by the newsletter cadence.

[japaric]

Nominating for discussion in the next meeting (#150)

[andre-richter]

Recently I was getting a bit lost about the what our stance here is regarding IRC vs discord. Information is scattered in quite some places.

It seems that both discord and IRC are options, but there is definitely more talk about IRC ongoing.

• Will we have a preference between both?
• Will we have private channels for the WG teams?
• Is Rust core using both equally or are there a less favorite child :D

If we want to prefer one over the other, should we make a vote?

[andre-richter]

What I like about discord is that it can natively live in a browser tab. It has good app support for smartphones, and logging is inherently provided. No bots needed.

[japaric]

@andre-richter The discord server is an "experiment" by the Rust core team. We have a channel over there because they created one for each domain WG (without asking any of us AFAIK).

Will we have a preference between both?

I haven't seen any current member of the WG (other than me -- I check the channel sparingly) use the embedded-wg discord channel. And I have received one comment (on IRC) about not wanting to switch the meetings to discord.

Will we have private channels for the WG teams?

We would have to ask someone on the core team.

What's the use case for private channels for teams I think it makes sense to have public channels for team but I don't see why they should be private. For private communication e-mail aliases (e.g. [email protected]) makes more sense IMO because outsiders can also communicate with the team. (If I'm reading Discord docs correctly outsiders can't see private channels, right?)

Is Rust core using both equally or are there a less favorite child :D

My impression is that the core teams are using more and more the discord channels for their non-video meetings.

If we want to prefer one over the other, should we make a vote?

We could make a vote, yeah. I want to point out two things here:

• At some point the core team was pushing for Gitter instead of IRC (like they are doing with Discord) but they abandoned it because it was too buggy (AFAIK). We might want to wait until discord gets some sort of "this is no longer an experiment" rubber stamp before committing to it.

• I heard from someone on one of the Rust teams that they were going to set up IRC <-> Discord bridges but I don't think that has happened yet. If they do set up bridges then preferring IRC or Discord would be up to each individual. I think indicating that the WG, as a whole, prefers one or the other would make much difference in practice.

[adamgreig]

I prefer IRC but mostly because I'm a long-term IRC user with a setup that suits me, including easy smartphone apps, logging, notifications, etc. Plus I'm always going to be using IRC for other channels, so swapping to Discord for one of them means adding a new service rather than replacing one.

I think the same might be true of a lot of long term IRC users, while for newcomers Discord is easier to set up and more feature rich. People could consider irccloud.com as an IRC client, which gives you a browser interface to IRC including logging and smartphone apps.

I heard from someone on one of the Rust teams that they were going to set up IRC <-> Discord bridges

If these work well then I could see this being the best solution. My concern would be if they end up like Slack IRC bridges which were somewhat feature restricted and then eventually removed altogether, after lots of people had moved to Slack. In a similar vein it's nice that the IRC server is hosted by Mozilla, whereas I understand the Discord server is proprietary and hosted by Discord.

[caemor]

@adamgreig doesn't irccloud also disconnect you after 2 hours of inacitivity? But as long as the new logbot works better than the old one that is not that big of a problem as you can just read all the missed messages there.

If I'm reading Discord docs correctly outsiders can't see private channels, right?

If a user doesn't have read access to a channel he can't see it. But you could also just remove the write access from non embedded workgroup members if you want a read-only access for non workgroup members. But i think they only have 4 roles setup for this server atm (core, lang, community, docs-team).

[therealprof]

Different solutions have different drawbacks. I used to use IRC a lot but those days are long over; now I only connect occasionally due to the pain of running and maintaining one or more IRC connections constantly. I prefer regular browser based solution nowadays and always have several Slack and gitter channels open.

[danc86]

I still use IRC every day for work. Matrix (the protocol) and Riot (the mainstream client) provide a nice modern solution for in-browser and phone use. It is a federated protocol and the implementations are all proper open source. The Matrix<->IRC bridge is high quality (aside from occasional issues of being overloaded) and the Matrix.org organisation hosts a public bridge for Mozilla IRC, as well as a public instance of Riot which anyone can sign up for.

Pointing new users at https://riot.im/app/#/room/#mozilla_#rust-embedded:matrix.org might be a reasonably friendly way to get them onto IRC.

[ithinuel]

Neither a big user of IRC or Discord (or slack or whatever) writing.

I would be more keen to use discord as I have restrictions on the network I use that prevent me from using IRC. Even if irccloud/mibbit exists I have to share my credentials with a third party that I'm not a huge fan of.

I would also advocate in favor of discord as it handles better the multiline messages, the images and the code snippets which have shown, in my experience, to be very use full.

EDIT: and AFAIK it does not require any maintenance from us (service, app, logs etc).

[awygle]

I've already got an IRC setup that works for me, but I know that's not true of everyone, and I do think the IRC barrier to entry is quite high. I'd really like for any solution to have at least a temporary IRC bridge solution.

I don't like Discord for several reasons, primarily because it's cloud-hosted and proprietary (IIUC). I don't particularly have a philosophical objection to that but it does make it a potentially ephemeral solution. Slack is at least less likely to go away (in my judgement).

Gitter is at least open source but I agree that it's quite buggy.

Mattermost exists? I really don't know anything about it though.

I am a big fan of the concept of Matrix, but I've never used it. If playing with Matrix/Riot showed that the IRC bridge was high-quality and the protocol lived up to its intentions, that would be my pick.

[japaric]

Can we please not turn this into a discussion about alternatives to IRC? That's off topic for this thread.

---

What I feel is more pressing is setting up e-mail aliases for each team. We need a two way communication channel between an individual, who may not be part of the WG, and a team both for reports of violations of the Code of Conduct and for applications to join the team.

@ryankurte can an external individual start a thread with a team using mailgun?

@nastevens @jamesmunns would it be possible to set up e-mail aliases under the rust-embedded.org domain (e.g. [email protected])?

[ryankurte]

Yeah, though you do have to manually re-add the team alias when replying (as a team member).

I'd propose we put them under @teams.rust-embedded.org for now, in case we want to do other email things in the future. Also that we need an authoritative source for aliases and where they go (one of these repos?).

I'd offer to do the mailgun setup, but you really need access to the DNS to add all the site-specific records.

[thejpster]

Yes to the subdomain, but minor nit - could we make it @team.rust-embedded.org. The plural 'teams' struck me as odd when read aloud.

As an aside we could also consider using the URL https://team.rust-embedded.org/.

[hannobraun]

@thejpster

Yes to the subdomain, but minor nit - could we make it @team.rust-embedded.org. The plural 'teams' struck me as odd when read aloud.

Hmm, doesn't sound odd to me. I prefer the plural, as that's a subdomain for the email addresses of various teams, not a single team. But I don't feel strongly about this, so feel free to disregard my opinion.

[adamgreig]

👍 for teams.rust-embedded.org. Not sure what we'd put on such a webpage though. As an alternative we could consider just [email protected], [email protected], etc. Even if we did something else with emails at that domain in future it shouldn't be hard to reserve those names.

[japaric]

+1 for teams.rust-embedded.org. Not sure what we'd put on such a webpage though

Maybe something like https://www.rust-lang.org/en-US/team.html ?

[ryankurte]

@thejpster as with @hannobraun I saw this as the collection of teams, eg. [email protected], but, I am ok either way too.

@adamgreig it's more to separate MX records than to reserve the names, in case we end up wanting person@ addresses or to do anything else with the root.

We also don't need to put any web content there, for now at least, it could just redirect to a contact page or the list of teams?

[japaric]

Done (team e-mails) in #189