Renaming to Remote Development group with Workspace and WebIDE categories
Situation
The main problems identified in our current state that have brought about this proposal to rename:
- Internal confusion around team names and responsibilities (ex. IDE vs WebIDE)
- Potential navigational confusion for GitLab users (ex. settings, documentation)
- uncertainty around if WebIDE and Remote Development should be thought of as one singular product or two separate products
Misson
These are the goals we should strive to achieve, in order of priority:
- Name for the product(s) that is easily marketable
- Name for the product(s) that is intuitive for users to understand and allows for simple UX design
- Name for the group that makes it easy for individuals internal to the organization to identify the group and it's responsibilities that differentiates from other teams
Our priority should be to establish a naming scheme for the products that prioritizes user experience. Subsequently, we can evaluate how this aligns with our internal organization. This approach may lead to both product and team naming following a unified structure or adopting distinct names based on the most significant benefits.
Proposed Product Change
| Current Product Names | New Product Names |
|---|---|
| Web IDE | Web IDE |
| Remote Development | Workspaces |
Proposed Team Change
| Current | New |
|---|---|
| Group::IDE | Group::Remote Development* |
| Category:Remote Development | Category:Workspaces |
| Category:Web IDE | Category:Web IDE |
*The name 'Remote Development' would be used only internally as a group name.
Why is this change being made?
The decision to treat Web IDE and Workspaces as distinct products stems from its potential for enhanced marketing and branding benefits. By presenting them as separate offerings, we can tailor our marketing strategies to effectively target different segments of our user base, highlighting the unique value propositions of each product. This approach also acknowledges the possibility that users may adopt one product without the other, emphasizing the importance of providing clear and focused messaging for each offering. Ultimately, considering Web IDE and Workspaces as separate products aligns with our goal of prioritizing user experience and ensuring that our products resonate well with our diverse user base.
We're also considering @tvanderhelm's suggestion that settings and configurations could be integrated closer to each product rather than requiring a central location for both. This approach supports the idea of allowing the products to exist independently.
One potential drawback of this approach is the potential loss of unified branding that comes with having both under a single product name. However, this can be mitigated through comprehensive documentation and tutorials that promote using one product alongside the other.
Author and Reviewer Checklist
Please verify the check list and ensure to tick them off before the MR is merged.
-
Provided a concise title for this Merge Request (MR) -
Added a description to this MR explaining the reasons for the proposed change, per say why, not just what - Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
-
Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI) - If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
Maintained bysection on the page being edited - If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
- The when to get approval handbook section explains the workflow in more detail
- If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
-
For transparency, share this MR with the audience that will be impacted. -
Team: For changes that affect your direct team, share in your group Slack channel -
Department: If the update affects your department, share the MR in your department Slack channel -
Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR - For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter
-