-
Notifications
You must be signed in to change notification settings - Fork 796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename Workspace to Dev Environment #600
Comments
I don't agree that renaming TL;DR:
1. CompetitorsCompetitors and similar products have adopted the term 2. Redefining what a
|
@ivan-burazin can you please provide more examples on "Additionally, adopting "dev environment" aligns with industry standards and practices.", except for Docker? |
Here are some points I’d like to address regarding the use of terminology for development environments:
|
@ivan-burazin I think my points were a bit misunderstood. I'm not saying that by using We need a named term for the development environment that Daytona manages and the question is should we name it I still believe that the strongest argument in favor of Lastly, They use AWS, from what I can tell, is the only product (that's not abandoned) that uses |
How can we market
Is doing something "jest because" competitors (in a niche market mind you) use it, a good reason?
What is this difference? They use dev environments, not Dev Environments? Also Space is a product on its own, like Codecatalyst and Dev Environments is a service inside it. |
Big difference. A development environment is just a noun that describes what they manage. It will be used in Daytona in the exact same way.
We won't market
It's not a "just because" argument, it's a "discussions were already held" argument.
|
I use capitalisation for Title Case purposes - when you use it in a title. Fine that it is
Same question as last time, how can we market
Who held the discussion? what is the argument? |
A
It needs to be capital case because it needs to be a name for environments that Daytona manages.
I don't know, but landing multiple times on |
Why?
Exactly thats why its not an argument |
The topic of this discussion is the name of environments that Daytona manages. Choosing either has nothing to do with marketing development environments because both represent development environments managed by Daytona.
Because we need a name. E.g. we need to have a section in the docs that explains what is a development environment managed by Daytona and it has to have a name, either The term
The fact that I suggest we stop here since we obviously don't see eye to eye and wait for others to chime in. |
If we consider our own definition, dev env is more than the workspace, it is a superset, for example it contains also an IDE. I would put it like this:
The line is blurry and can be moved. I don't like that Dev Environment is a two word construct. Environment would be better in my opinion if we are considering this. For example: "The user can have multiple projects inside the same Environment", this is wrong atm, as for each repo we setup separate "environment". I was avoiding to contribute here, as I have more confusion with Workspace - Projects relation. :D For example Github removed "Projects" and is now using repositories as term. This honestly, is not correct 100%, but I can understand that for typical user this brings in more clarity. So some of the options could be:
I agree that this is an important point, as the actual renaming would be impossible at the later stage (or really confusing and hard). It is always a question of spending time to educate. But also, I am not feeling terrible pain point here, and it could stay as is. |
Of course it does. Example I am on a demo/presentation and state we "manage development environments" then on the next step i say now go to "workspaces". I have done this 100+ times and very often people stop me and say "what is a workspace?" Using "Workspace" means introducing a new term, each new term complicates the experience for the user. |
A |
Also, Niko mentioned our definition above. That's a definition for a development environment. If we choose to go with |
Using direct terminology like "Environment" could minimize the cognitive load on users, who might not immediately understand what a "Workspace" is. Two-word construct is too much. But ideally, we could survey the user base. |
@ivan-burazin CodeCatalyst does not use the term "development environments" to describe instances of development environments. JetBrains uses "Dev Environments" and that is a name for their instance of development environment: Personally, CodeCayalyst is much more appealing to me as it is a unique name that is not similar to the term "development environment". |
The issue with unique names is that you need to explain them and educate the user about them. CodeCatalyst doesn't convey information by the name itself on what it does. I think this is the main point of this issue as raised by Ivan. Reducing the cognitive burden of users. |
What is there to explain for the "Space"? It is as obvious as it can be. |
JetBrains Space: The Intelligent Code Collaboration Platform it is not the name of the Dev Environment product |
I'm not talking about JetBrains, but CodeCatalyst |
Please elaborate this then, do not follow:
|
CodeCatalyst Space - the name of the development environment instance |
Adding more context on the CodeCatalyst naming. Space - Project management context - eg. abstract organizational unit. |
CodeCatalyst DevEnvironment is one per repository. Each Project consists of multiple repositories (one or more). |
There is ambiguity with the naming of Daytona "Projects" that we need to sort out before we continue the "Workspace - Dev Environment" discussion. |
I would argue that the parallel to the CodeCatalyst naming would be:
I think it's pretty clear this is a very subjective matter because, in my mind, I wouldn't associate a Project as having multiple repos that can have multiple dev environments. |
The goal of the discussion is to find the naming solution that aligns with what developers are used to in the best possible way. So I'd avoid subjective matters. |
Revisiting the initial naming convention, the "Project" is a contextual boundary around the single repository (or a project folder in case the same doesn't have a git repository - for example, a local project). Daytona Workspace concept is very similar to the Devfile structure, while CodeCatalysts features a different paradigm for what the CodeCatalyst Project is used for. Therefore I would conclude that the "Project" as a part of the "Workspace" makes sense and should stay. |
Closing in favor of #747. |
Is your feature request related to a problem? Please describe.
Renaming "workspace" to "dev environment" in DAYTONA can significantly improve clarity. The term "dev environment" is more specific and recognizable to developers, as it directly indicates a space meant for development-related tasks.
This specificity eliminates the ambiguity associated with the generic term "workspace," which can refer to any work area and not necessarily development.
Additionally, adopting "dev environment" aligns with industry standards and practices. Example; Docker uses "dev environments" to describe its configurable spaces for development. On the other hand, GitHub uses "codespaces" for its cloud-hosted development environments, while reserving "workspaces" for different purposes within their broader ecosystem
The text was updated successfully, but these errors were encountered: