Proposal: Adopt Workspace terminology for Remote Development
Proposal
Adopt the workspace
term to use for the upcoming Remote Development product offering. Re-name groupworkspace and how we position the existing concept of a top-level "workspace".
Why make this decision now?
The Remote Development category is fast approaching a public-facing MVC and we need a way to describe the concept of a fully configured, ephemeral, remote environment in both the UI and documentation that is descriptive and succinct, in keeping with our product naming guidelines. Meanwhile, the ongoing work that groupworkspace has been doing is becoming increasingly impactful as they iterate toward their vision and in the near future the major concepts of a top-level workspace will begin to impact the structure of GitLab.
The longer we wait to re-align the term workspace
, the more tightly associated with the organizational pattern it will become.
Justification
Competitive analysis
While Workspace
is a generic term that can be applied in a variety of ways on a variety of platforms, one insight we gleaned from the competitive analysis is that for companies that had both a concept of a top-level namespace and a remote development offering, the term Workspace
was always used to describe the remote environment.
Companies that do not provide a remote development offering tend to use Workspace for the highest level of organizational capabilities in an implementation.
More detail can be found in Workspace naming (gitlab-org/gitlab#373939 - closed) and Naming Remote Development offering (#4812 - closed).
Most of the competition in the Remote Development space use Workspace
as the primary or secondary term when describing their feature in the UI and documentation. Gitpod, JetBrains, Eclipse, and Cloud9 all use workspace
. The notable exception is GitHub Codespaces, which is a derivative.
Analysts take
While results are still pending, it's generally to early in the feature's adoption for analysts to have a clear position here. There's no magic quadrant for it yet, but as a category they generally agree that Remote Development Environments
is the most descriptive name. However, we need something more succinct to describe the object that we interact with when working in a remote development environment, and that is almost universally referred to as a workspace
User research
@leducmills recorded a summary of a recently-concluded survey. In the survey we found that the term workspace
was more closely associated with the Remote Development feature set. The terms most closely associated with the current focus of groupworkspace were Organization
and Admin Console
.
Impact
[Work in progress]
While the immediate impact of finding a new name for groupworkspace and untangling the internal and external association with the term will be significant, by aligning our Remote Development offering to an almost ubiquitous term in the competitive market we capitalize on the existing mental model customers have in this space.
From the angle of groupworkspace, customers will not be confronted with the chosen term too much in the UI. The only place where customers might interact with the term are the documentation and potentially an alternative name for what we currently consider top-level groups. Organization
seems an acceptable alternative. Admin Console
has a too narrow focus, as not just admins will be able to access this organizational layer.
To avoid confusion about responsibilities when looking at the handbook, groupworkspace might need a new name. We suggest group::organize
as an alternative. None of the current categories currently contain the term Workspace, so the term would only need to be removed from current documentation. However, it would continue to appear in issues and comments for possibly years to come. We might also need to re-educate Sales teams, Marketing, etc. on the new terminology.
Implementation
Effort for groupworkspace is captured in this issue: Rename Manage:Workspace to Manage:Organization (www-gitlab-com#14254 - closed).