RFC: Add a dev-announce channel for engineering-wide announcements

[pam-]

Proposal:

Add a dev-announce channel for announcements that impact the engineering team.

Some examples:

• Deploy locks
• Breaking changes
• Tooling & infrastructure upgrades
• Structural changes impacting the eng org (e.g. new teams, staffing changes, new processes)
• GitHub (or another external dev service) is down

To avoid folks getting excessive notifications, there will be a zero-chatter policy except in threads.

Reasoning

Messages tend to get lost among the automated bot notifications and the general chatter when shared in #dev, this results in a loss of context that only gets bigger if things have been shared during someone's time off. Additionally, because all the dev-related announcements land in the same place, it eliminates hierarchy and leads us to rely on the @devs tag to signal messages with impact at the org level.

How this RFC is resolved

We'll collect feedback on this RFC from the team for two weeks. We'll consider this RFC approved if 50% of the engineering team actively approves of this change. Add a 👍 or 👎 reaction to this proposal to vote.

[pvinis]

For context:

• #dev has announcements by humans, plus open-eng cal events, oncall reminders, horizon blocks etc by bots.
• #dev-offtopic github/twitter notifications by bots, and random banter by humans.
• #dev-banter humans chat about dev stuff.

To me, the current setup works fine. all business-important and dev-important stuff are in #dev, all non-business-important stuff are in #dev-offtopic, and #dev-banter is just free.

There is no random chat in #dev. Scrolling back, all messages that are by humans are important or should be visible by all or most devs. It's basically what you are suggesting for the new channel. I don't see how it's any different?

[patrinoua]

@pvinis thanks for clarifying what the existing channels are for. I'm wondering if we can update the descriptions of these channels on slack so that it's clearer for everyone and also provide more context here?

[SamRozen]

I think it's also worth clarifying the expectations re what's mandatory vs optional. I've heard repeatedly that some people feel overwhelmed because they believe they are expected to be active in dev-help, dev-banter, etc.

Something like: Channel X: mandatory for people doing A Channel Y, Z: optional reading for fun

Could also help here.

[lidimayra]

I see a lot of value in a channel focused on announcements only.

Today we use the #dev channel for anything that's business important, regardless if it's something important just at that moment or if we really want to ensure that every engineer at Artsy sees it. And then we end up using group notifications (channel, here, developers) in the second scenario, hoping those will stand out. This leads to several notifications and in the end, it doesn't even seem effective. I raised some concerns related to this in this thread.

I would suggest some changes in the ones that we listed in the description though. I would rather something like:

---

Deploy blocks (#dev) Breaking changes (#dev-announcements) Tooling & infrastructure upgrades (#dev-announcements) Structural changes impacting the eng org (e.g. new teams, staffing changes, new processes) (#dev-announcements) GitHub (or another external dev service) is down (#dev)

---

For an engineer that spent 1 week off, it's really easy to miss some important messages in the middle of several ones that lose relevance as time goes by (like deploy blocks, oncall reminders, etc).

If we had one specific channel focused on announcements only, it's easy to have a separate channel only for stuff that shouldn't be missed regardless of how much time has passed.

it eliminates hierarchy and leads us to rely on the @devs tag to signal messages with impact at the org level.

I would think that if we have a specific channel focused on announcements only, ideally, no tags should be needed, not even @devs. The norm could be that everything that happens in the channel is relevant and should be followed by every engineer. at Artsy And then mentions could be used only for stuff that's urgent.

[joeyAghion]

In my recent experience taking a few days off, there were 10-15 messages per day in #dev, most of them automated announcements of deploys or events (and almost no off-topic chatter). I found that volume very easy to catch up on.

Of course we all love to question and debate, and it's natural now for that discussion to follow (in a thread) from the dev-wide "announcement." Those conversations can go in unexpected directions, and it would be awkward to migrate to a different channel to discuss tangential topics.

For those reasons, I think I prefer directing announcements to the existing #dev channel. If anything, I'd clarify the expectation that information relevant to our work is communicated there, so engineers should follow it.

[pam-]

Thanks for the feedback all!

@pvinis -- I'll echo @lidimayra's point to answer your question: having a separate announcement channel would make it easier for visibility and long term relevance imo. It would also avoid the use of pings and the potential stress/distraction that come with them + make the announcements visible to all who wish to follow big engineering things without having to commit to joining #dev and following the banter in there.

@lidimayra -- your suggestion for message hierarchy makes sense to me!

I agree with the points about clarifying the channels purpose! But that doesn't solve the issue of messages getting lost :(

Lastly, please remember to vote on the RFC if you haven't! There's a week left!

[mdole]

Really interesting proposal, thanks for surfacing @pam-!

My vote would be not to create a new channel, but to give #dev a little attention. I think we could continue to use #dev for all important teamwide announcements, but make 2 changes to keep the signal-to-noise ration very high:

1. Stop using it to announce deploys. I think this practice is a bit outdated given the size of our engineering team and our confidence in deployments - most of them happen automatically now! I think it's good to call out a particularly big deploy, or to check in with someone if they have work in a deploy you want to make sure is OK to release, but I think it should be optional instead of standard at this point
2. Clean up some of the automated messages. I agree that there are too many right now and other things can get a bit lost. Doing a quick scroll through, here are examples of messages I would propose getting rid of:

• All "engineering open calendar" messages

  

• Horizon messages about auto-deploys (this one I'm a little less certain of; feels like it would be nice to have these somewhere but they do create a lot of noise)

• Most Slackbot messages, e.g.:

Hopefully this doesn't derail the discussion too much - happy to wait for this RFC to be resolved and follow up if that's less confusing :)

[kajatiger]

I don't have any strong feelings about this and am okay with any of the above ☺️

[patrinoua]

Hi all, @pam- thanks for bringing that up and everybody for their contribution to the discussion. Adding a clear description regarding the scope of each channel as Pavlos and Lidi suggested and cleaning up the existing channels of redundant notifications as Matt suggested would make the most sense to me.

[erikdstock]

Though I share some of the issues this RFC is trying to address I tend to agree with the points raised by both @mdole and @joeyAghion - If we remove some of the less relevant notifications and communicate expectations similar to our incident channel that

• developers read everything posted there
• conversations happen in threads

I feel like that would address most of my pain points here. I think I would still support a weekly announcements including active RFCs, team-wide standup announcement, tech plans, etc.

[sweir27]

Thank you for starting this discussion, @pam- !

I agree with the above points to keep the #dev channel for announcements (that's what I thought its primary purpose was anyways!), but to clean it up so it can be more effective.

I also agree that clarifying slack channel purposes and having SLAs for devs (which channels are you expected to keep up-to-date with, etc.) can help our whole slack space be less confusing.

I do think having a record of deploys can be quite useful when trying to debug issues in production. However, this need seems clear enough that if anything, I'd pull those out of #dev and have a dedicated #deploys channel. (And bonus: can these notifications be automated??)

[pam-]

Thanks for all the thoughtful comments y’all! 🎉

Closing this out with 5 👍 and 8 👎

Next steps:

• Audit the automated messages in #dev and agree on what needs to be disabled or moved.
• Automate deploy announcements and move them to a #dev-bot channel, along with the other automated messages from #dev (good future-fridays project!)
• Re-iterate the purpose of the #dev- channels to the team once all of the above is done.

Let me know if there are strong objections! Otherwise I will proceed 😄