RFC: We are all solely responsible for ensuring that we are not disturbed outside of working hours about readme HOT 16 CLOSED

For me, I'm cool receiving whenever. I always send with a [for the morning] or using the slack send-later thing.

That's the idea of this RFC: to remove that moment of "do I label this [for the morning] or do I schedule it for later or do I just wait or do I ... ?" and to make communication as frictionless as possible. If we always assume that the receiver has set things up the way they want them, we can just send the message without having to think about externalities.

(And of course it's totally up to you, but I would ask you to consider not receiving whenever, and instead maintaining a border between work time and non-work time)

from readme.

I also agree that people who are sending messages shouldn't have to think about timezones when it comes to an environment that relies on async communication.

First off, I actively dislike getting messages off-hours on Slack. I'll just come out and say that. For one, I have a bad habit of occasionally checking Slack off-hours....this results in all my notifications being cleared, but I'm usually not in a position to respond to the message adequately. Then, the next time I'm at my computer and open Slack...all my Slack notifications had already beeb cleared by that off-hours check-in, and so I continue w/o following up on those messages,
having already forgotten. It's embarrassing how many times this has happened to me. I don't want to feel like I shouldn't be checking in off hours like this occasionally? I frequently wish that the notification/message had simply been delayed until the following working day.

In this scenario, wouldn't the Mark Unread option solve the issue?

Maybe the message should be posted in a public channel (like the relevant product one, or a #dev-related one) without needing to @ anyone specifically? If you are generating a lot of off-hours notifications for people, that might also be good to look into why that's happening

I agree 100% with this part. It would be really good to put up some effort to always consider sharing questions in public channels unless there is an actual reason for it to be private. It removes the unnecessary dependency on specific team members and it also generates documentation as history for people with similar questions.

from readme.

I don't have a vote here for yes or no. I think the most important thing is to document these so people know how to do it, and then everyone can do what they want.

For me, I'm cool receiving whenever. I always send with a [for the morning] or using the slack send-later thing.

As long as we make sure to make it very clear that no one is expected to answer random messages off-hours, and give all the ways that tools/apps can help, then I think that's enough.

from readme.

@lidimayra, good point about the Mark Unread option, I will give that a shot! I overlooked that one.

from readme.

There is also the option for people to send messages later:

from readme.

Right, but that's what I want to do with this RFC: make it explicit that it's the responsibility of the recipient, not the sender.

from readme.

If so do we need to make explicit when, if ever, you as sender may override someone's hours (i.e. "so and so has notifications off, notify anyway")?

from readme.

Good question. I honestly think that there's never a need to override someone's notification settings. But I guess we could explicitly call out a super extreme case, something like "(artsy.net is down | the app is not working) and no-one else can do anything about it"?

from readme.

I'm in favor of this RFC. This will make asynchronous communication a lot more easier. I would also explicitly add that, by default, response to a slack message are expected within the recipient business working hours unless explicitly stated otherwise.

I wonder if we should also tie into the RFC any expectations related to OpsGenie being properly configured for escalation outside of business hours? Or maybe it's already covered on the on call side of things ? cc @joeyAghion

from readme.

I'm very much in favor of embracing that Slack (and Github and e-mail, but especially Slack) is asynchronous and so the timeliness of a response is up to the recipient and implicitly "when convenient." That should include direct messages and @-mentions. In the occasional cases where a timely response is helpful, that expectation must be made explicit (e.g., "I'd like to resolve this by end-of-day so...").

Current on-call docs do set the expectation that engineers have the OpsGenie app installed and contact methods enabled. A "central notification template" standardizes how the app and other methods (voice/SMS) are used to reach engineers, though individual devices can be disabled.

from readme.

I am in agreement with the main premise of this RFC (that we are each responsible for setting up our notifications in a way that suits you, for some someone may like being able to check Slack often from their phone, for others they won't have it installed on a mobile device unless it is on-call).

However, I have a slight disagreement about the more nuanced premise, which is about frictionless communication and sending Slack messages off-hours.

First off, I actively dislike getting messages off-hours on Slack. I'll just come out and say that. For one, I have a bad habit of occasionally checking Slack off-hours....this results in all my notifications being cleared, but I'm usually not in a position to respond to the message adequately. Then, the next time I'm at my computer and open Slack...all my Slack notifications had already beeb cleared by that off-hours check-in, and so I continue w/o following up on those messages,
having already forgotten. It's embarrassing how many times this has happened to me. I don't want to feel like I shouldn't be checking in off hours like this occasionally? I frequently wish that the notification/message had simply been delayed until the following working day.

Secondly, I do think it's very valid to stop for a moment and double-check with yourself if this is necessary, before sending a message to someone that's clearly off-hours. I don't think that's a large enough mental load or ask to meaningfully impact communications or add friction. I think that's a good pressure to have, maybe this is something you could find out the answer to yourself with a bit more independent digging? Maybe there's a more appropriate person in a different time-zone available to ask? (and if not, we should be spreading the wealth and reducing the bus factor). Maybe the message should be posted in a public channel (like the relevant product one, or a #dev-related one) without needing to @ anyone specifically? If you are generating a lot of off-hours notifications for people, that might also be good to look into why that's happening (maybe you can adjust to work on more independent items off-hours, and try to overlap with people for more timely group work that's likely to require collaboration like that). Finally, I think the 'scheduled send' is a great thing to then use if necessary- likely to schedule to post in the relevant Slack channel (I think 99% of all DM's (besides those about some personal business) are probably fine to just happen publicly anyway).

So overall, I do agree with the premise and I'd love to come up with a more explicit policy. I do sort of disagree with the conclusion that we seem to be getting at here of 'assume the recipient is adequately set up and feel free to send w/o a further thought'.

from readme.

Maybe outside of the scope of this discussion, but related to @joeyAghion 's comment

Current on-call docs do set the expectation that engineers have the OpsGenie app installed and contact methods enabled. A "central notification template" standardizes how the app and other methods (voice/SMS) are used to reach engineers, though individual devices can be disabled.

I think that as long as Artsy does not hand out work phones, the company can hardly ask me to install anything work related on my private device. Technically I don't even need to have a smartphone and I am very opposed to having work related apps on my private phone. From a legal point I cannot imagine that this is even legal in Germany. I would not count on people installing ops genie on their phones when having on-call duty.

from readme.

This conversation had me finally set up the routing for work comments to stop showing up in my private email.
I suggest that as part of this RFC we also add to onboarding this expectation and the documentation of how to turn off notifications per which tool. (and set focus time)

from readme.

+1 to all of:

• Mark unread
• Remind me...
• defaulting to open channels, where more people are able to respond at times that are convenient for them

from readme.

Yes, good point @kathytafel. I opened a PR to adjust the onboarding checklist and assigned it to you!

from readme.

Resolution

We decided to adopt this policy.

Level of Support

3: Majority acceptance, with conflicting feedback.

Additional Context:

Most people were in favour of it, but there were some extensions (adding an onboarding step), some unresolved questions (opsgenie) and some diasgreement over details.

Next Steps

From now on, we should all assume that everyone has set their notifications up so that they will not be interrupted. This means that we shouldn't worry whether someone is at their desk when sending a message. But also, to reiterate, we should default to open channels for communication where possible.

There's a new Taming Notifications Playbook with tips about setting up your notifications - please feel free to add to it!

Exceptions

If they can, engineers should leave notifications on during down time when on call (but this is not obligatory).

from readme.