Page MenuHomePhabricator

Remove "Away" and "Sporadic" statuses.
Closed, ResolvedPublic

Description

As of right now, distinguishing between "Away" and "Sporadic" isn't particularly useful. The use case where expected away time is important is when waiting on a code review. However, an "Away" status is automatically added to any user who is listed on a calendar event as of "right now" at any given time.

Status is useful to determine expected unavailable time, and simply reading the user's calendar availability should suffice for that. Unless other use cases come up.

Event Timeline

lpriestley assigned this task to epriestley.
lpriestley raised the priority of this task from to Normal.
lpriestley updated the task description. (Show Details)
lpriestley added a project: Calendar.
lpriestley added a subscriber: lpriestley.

@btrahan, @chad, curious if you guys have any use cases for "Sporadic" vs "Away" -- I couldn't really come up with any, and if we don't get rid of this we probably need to make it per-user instead of per-event so it would be simpler to toss it if we don't have a good use case.

It exists this way in the product only because it existed this way in Facebook's stuff.

I think these are pretty useful. Common case for "sporadic" is working from home or some other exotic location where you can't be reached physically right away.

(I do think since we all work from home all the time it breaks down in the Phacility case a bit. Additionally, these terms will mean different things based on local work styles.)

Most generally, status to me is about when to expect any sort of response, not necessarily just code review. Sporadic means expect a response less quickly than normal while Away means go ask someone else.

Long term, I'd expect the "status" to be a custom field that folks can configure and then have workflow around. (e.g. "this guy status type is "in the datacenter" so the auto escalation goes to the next guy) That's "very long term super far out we can add this back later when those features become more nascent" far out, but figured I'd toss it out here.

In a future where we have automatic escalation rules, "escalate automatically" vs "do not escalate automatically" makes sense.

For appointments/meetings with a short duration, I think the distinction between "expect a delayed response" vs "expect no response" probably doesn't matter much: at 12:30 PM, "sporadic" until 2PM and "away" until 2PM are basically the same in all cases. We already show this information and can continue to show it (and maybe emphasize it more).

I can maybe see this distinction mattering to distinguish between multi-day events ("totally off the grid" vs "business trip"), especially if we end up revealing less information about the nature of events to other users in the future (in HEAD, they're pretty private by default).

No matter where we end up, I think if this exists in the future it should be a property of the invitee/user, not the event, so I'm going to mostly rip that bit out out, but I'll leave the concept of a partial/sporadic availability around until we have a clearer long-term picture.

D12857 should fix the issue with list views (including /upcoming/).

I think this is something we'll probably revisit in the long run but it's probably a v2+ type of thing and I'd expect it to be informed by other product decisions between now and then (and possibly by application changes like having meaningful automatic escalation).