Shared workspace times out if workspace creator is idle but other collaborators are not

[Mob-Programming-Meetup-Austria]

Bug description

We run a frequent Mob-programming meetup, where gitpod serves us very well for collaboration with low setup overhead for our participants.

It looks like the session times out if the workspace owner is idle for some time, even if the collaborators are actively using it.

In our sessions, sometimes the main collaborators are different users than the owner of the workspace (and the repo). It would be nice if also the activity of other users would be checked.

Steps to reproduce

1. Start a workspace
2. Share the workspace with somebody else
3. Only interact with the workspace from the other user
4. Session will time out after a while

Workspace affected

bronze-iguana-w9e78jfb

Expected behavior

It would be nice if the workspace owner doesn't have to restart the workspace.

Example repository

No response

Anything else?

No response

Front conversations

[gtsiolis]

Thanks for bringing this up, @Mob-Programming-Meetup-Austria! 🍊

issue: This seems to conflict with the notion of ephemeral dev environments[1] and surface a way to exploit the platform as this could easily break user control[2].

thought: However and more importantly, I think the use case you are describing fits better when collaborating asynchronously and here Snapshots[3] could probably be a better way to share the workspace in the first place and allow collaborators to work on their own and possibly share a new workspace for the outcome. Also, in case this could help, there's also a feature to extend workspace timeout[4] for 180 minutes which is currently available in the Unleased Plan. 💭

Adding here the feature: collaboration label. 🏷️

Looping in @jldec for input.

[Mob-Programming-Meetup-Austria]

Thanks for the timly response and great suggestions @gtsiolis

Unfortunately our events are live and synchronous collaboration sessions. We rotate the "Driver" role every 3-5 minutes while we do mob-programming. Usually we set the rotation time so that the first driver is back at the "keyboard" after 20-30 minutes at least in the ideal case. Often while practicing it takes longer to do a full round within a group. This means we hit the default timeout quite regularly.

Thought: Would a notification (5-10 min before timeout is reached) be a potential mitigation of these conflicting "requirements"?

Thanks,
Harald Reingruber

P.S. Here is a link to our meetup group, just in case you are curious: https://www.meetup.com/Mob-Programming-on-Open-Source-Software/

[gtsiolis]

@Mob-Programming-Meetup-Austria I think once we add better and more granular sharing (#4841) and introduce the new teams pricing (https://github.com/gitpod-io/roadmap/issues/17), it would be it easier to effectively tackle this use case. Cc @jldec @svenefftinge

For example, 🅰️ using a team[1] for this meet up group and 🅱️ sharing a workspace to all team members could make it easier to allow collaborators to continue working on a workspace without timing out while using team credits / billing / usage quota.

A notification before the timeout could easily go unnoticed and continue blocking users as the workspace owner could be unavailable. 💭

[dpolivaev]

I am also a member of the @Mob-Programming-Meetup-Austria group. I would like to clarify one point in our use case.
Actually, the workspace owner is always present in the session. They are just not typing until becoming a driver again, but the connection with their browser is never lost. Therefore everything happening in the session is always observed by the workspace owner. If the timeout would not occur just because the owner is not typing while observing the running session it would be very helpful.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.