Bitbucket Workspaces FAQ

[#1]

Q: Why Workspaces?

When we first started working on changes to make Atlassian products compliant with General Data Protection Regulation (GDPR) we decided that users should not own content nor have their usernames exposed in URLs.

At the same time we are seeing a trend of larger teams and teams of teams collaborating in Bitbucket. It no longer about a single team of developers but a larger organization. We wanted a new concept that better accommodates larger and larger groups of developers.

Workspaces provides users with an extra layer of anonymity when working on personal projects while also evoking a larger collaborative space for large teams.

Q: Will Workspaces affect my plan or bill?

No. Bitbucket plans and billing are not affected by Workspaces. The number of users on your plan will not change.

Q: Will this affect my repositories or other content?

No. All of your repositories, users, snippets, etc. will remain exactly the same as they are today. All of your URLs will remain unchanged so none of your users need to change anything in their git clients. Users that don't log into the Bitbucket web application will never know that anything changed in Bitbucket.

Q: Why do I now need Projects for my repositories?

Projects already exist within teams today. Projects add the ability to categorize and group repositories. With the move to Workspaces we are now requiring all repositories to belong to projects. In the future we plan to add new features for projects to make them much more powerful such as: project settings, project permissions, project dashboards. 

Workspaces will let us unify the experience of working with projects and repositories so we can more easily add new features in the future.

Q: Where do I find my settings?

You can manage your Personal settings, which was previously a part of Bitbucket settings, from your profile avatar. To access your Workspace settings, go to a specific workspace and click on Settings in the left sidebar.

Q: Will this affect the API?

Yes. We are deprecating the separate `/teams` and `/users` endpoints with a single `/workspace` endpoint to simplify integrations. With a single object "Workspace" applications no longer need to track the account type separately. The details of this change can be found in the Developer documentation.

For more details on Workspaces and what's to come see our announcement.

[SJL]

I think this is good.. a welcome change and the right direction.

It would be great if you also have way to enable a "manifest file", maybe at the project level, so all the repos inside of the project has its details linked to the manifest. This would be useful to have since version of the app/project, while also maintaining the integration details of each repo in the manifest file.

[Thomas Sondergaard]

I wish you would focus on making the core of bitbucket really strong instead of doing more and more. At least 90% of my interaction with bitbucket is via two interfaces

* git

* pull requests

Both things work, but they are not great. git push and git pull is not fast. Compared to when we had a local repo, they are downright slow. I think the fact that I'm in Europe makes it worse. Last I visited the US I had much faster git push/pulls. Regardless, this simple every day task that I do many many times is slow and it matters. In comparison, I couldn't care less about workspaces.

Pull requests is the single most important feature in the bitbucket web interface for me and my colleagues. And both the old and new pull request experience is a bit underwhelming. Why can't I review Pull requests commit-by-commit? Why can't I add multiple comments before submitting them as a review in one go?

I strongly encourage you to get the core functionality fantastic before spending resources on anything else.

Thanks,

Thomas

[Kay Likes]

How does this affect two factor authentication? 

I agree that the core of Bitbucket needs help and we are already using Jira for projects.

The permission structure is not as flexible or secure. Bitbucket is for git, pull requests, and also is more subject to audits.  It looks like Workspaces is basically just another word for Projects which is in Teams. 

There are people that have access to other Atlassian items in Jira or Confluence that should NOT have access to Bitbucket. 

I would also like to see better options for setting up pre- and post- commit hooks rather than this change.

Thanks,

Kay Likes

[Bjarne Svanberg]

The graphics shown in the article suggest that the old teams account cannot have multiple repositories under them, which is not true. The existing/old teams account can already have a project with multiple repositories associated with it. This sounds like a "fix" for a non-existing problem.

What have always bothered me is the fact that I was forced to create a project in BitBucket for any repository, even though I am already managing my project in JIRA!

"Hey BitBucket Team! In case you don't know, the other end of your company is building a project administration tool called JIRA. Try to collaborate with them and incorporate JIRA... or at least try to use it."

Get your shirt together

-B

[Bjarne Svanberg]

And if it wasn't clear from my previous post, please do not "...add new features for projects to make them much more powerful...". We already have projects in JIRA! Re-use them! Integrate with them!

[Michael Kuhl _Appfire_]

@Patrick Wolf - Atlassian  - Can you update the Developer Documentation link with a deep link to the page(s) that document the changes?  There is nothing obvious to me on that page that discusses the changes.

[gbuday]

I have the following use case: I am an instructor and I would gather my students' repositories into one workspace. However, I would like to see all of their repositories but I want that they would not see each other's repository.

Is this doable with this new feature?

[Patrick Wolf - Atlassian]

I can't respond to each comment directly so I'll try to respond here to all:

@Thomas Sondergaard - Yes, we still have a team dedicated to improving the PR/code review experience. If you have direct feedback I can connect you with that team to learn more about what we are doing there.

@Kay Likes  - This has no impact on 2FA or how you interact with git.

@Bjarne Svanberg  and @Kay Likes Workspaces is a higher level than Projects. Projects belong to a workspace. We want to include more project support in Bitbucket for several reasons:

1. Bitbucket Server has projects to organize repositories. We hope to make the experience on Cloud and Server much closer for users.

2. We want to enable simpler management of repositories by allowing users to have multiple repos in a project that all share the same settings (Default reviewers, branch strategy, etc) and same permissions so you don't have to configure every repository individually.

3. We want to align better with Jira projects so that a project might span the products. Settings, permissions, reports could be more centralized without repeating steps in each product.

You can always have a single project in Bitbucket if you like for all of your repositories. You don't have to create new projects if you don't want to. If you have other use cases that don't work in this model, please, let me know.

@Michael Kuhl _Appfire_ - Yes, the deprecation notice will be posted in a day or two with all the API changes. We had a few last minute edits to make before posting it.

@gbuday  - Yes, you can still set user access at the repository level. That doesn't change. What will change is that your Members view will show you all users that have access to your repositories giving you better visibility across them. It won't change your ability to restrict a user to a single repository.

[Kay Likes]

@Patrick Wolf - Atlassian  - Does this mean that I will need a Workspace AND a Project?  The illustration seemed to indicate that Workspaces were replacing Projects in Bitbucket. If I have to do a Workspace, then a project, then finally create my repo, that is a lot of overhead when all I really want is a repository.

Will the repository user access override the Workspace user access or visa versa?  

Will I still be able to just have a view where I can see all the repositories for the company?

" Members view will show you all users that have access to your repositories" by "Members view" do you mean Admins?

Also, is there a way to have different admin levels - i.e. - you can be an admin on who has rights to access Bitbucket, but then have separate admin rights to create repos and add users to them?

Thanks,

Kay Likes

[Shahid_Sabir]

@Patrick Wolf  Please explain the below quote further for me to better understand   

  "You can always have a single project in Bitbucket if you like for all of your repositories. You don't have to create new projects if you don't want to. If you have other use cases that don't work in this model."                             

[David Smedberg]

Will Snippets also be grouped inside Workspaces? So I can create different workspaces for different sets of snippets?

[Jay Seletz]

I currently have to manage duplicate branch permissions across 61 repos, a very painful process.  It would be FANTASTIC if this will be improved with workspaces.  It is also very hard to see build/branch status across so many repos, the single Team view of repositories is not very useful.  We create the same feature, release, and hotfix branches across multiple repos, visibility for the same branch/pipeline status across multiple repos would be AWESOME.

[Deleted user]

This seems like a good improvement overall. If I understand correctly, Workspaces is a higher level than Projects, does this also mean there will be no changes in the user's experience? E.g. will their layout of repos/menus/etc. change?

[Mark Hughes]

It would be great if this allowed multiple workspaces across the team, and sharing the groups across the workspaces. 

[Patrick Wolf - Atlassian]

Hi, everyone. I meant to respond this weekend.

@Kay Likes : Workspaces contain Projects and Projects contain Repos. You don't need more than a single project in your Workspace if you don't want to deal with projects. Permissions are based on most permissive model. If I give a group Write access to a repository then everyone in that group has Write access even if a user is specifically given Read access. Alternatively, if a group has Read access I can give one user Write access at the repository level.

@Shahid_Sabir : You need to have your repositories in a Project but you don't need more than one Project. If you use a single Project for all your repos then you don't really need to deal with projects at all. 

@David Smedberg : Yes. Snippets are contained with a Workspace

@Jay Seletz : Yes, we recognize this is currently an issue. Workspaces doesn't really help solve this problem but we do hope to use Project settings to configure all repositories in a Project at the same time.

@[deleted] : Yes. The one exception to the layout is that personal settings for your user have been separated from the Workspace settings. Prior to workspaces all of the common settings for your repositories (Groups, Oauth Consumers, App installs) were intermingled with your user settings (ssh keys, 2fa, app passwords, notifications, etc). Now your "Personal Settings" are things only applicable to your user and there is a separate Workspace settings that apply to your repositories.

@Mark Hughes : The goal is kind of the reverse. All of your teams will belong to the Workspace and you can group the repositories into Projects. Groups would be shared across projects and eventually projects will offer better compartmentalization and autonomy from each other.

[Daniel]

Within workspace settings, what does "Keep this workspace private" mean and why is it off by default?

[aldocaruso]

Which is the relationship between the visibility flag ( public or private ) in its three levels of configuration (  Workspace, Project and Repository ) ?

I find the following inconsistency: while a private project prevents its contained repositories to be public ( which is coherent ), a private workspace allows its contained projects to be public ( which is not coherent ). Furthermore, these public projects can contain public repositories as well.

[Andy Burgess]

Is there a beta group I could join? I have a new project that I'm just setting up and I think the new features would be really useful.

[Tomáš Vojvoda]

@Patrick Wolf - Atlassian 

Please answer us here the question of what "keep this workspace private" means? It is not explained in the application, no tooltip there, nothing. And it is quite literally the first thing I need to decide when I want to setup Bitbucket.

Maybe you count on the notion of "private" being generally understood by the community, but some might not understand it or be unsure - like me, and this does seem important.

Thanks.

PS: what I find very helpful with these things is when you write in brackets something like "you can change this at anytime in workspace settings" - that really takes the stress of making wrong decision off :)

[Shereef Marzouk]

How do I access labs for my workspace account ??

[amomchilov]

Can workspaces be nested in other workspaces, or project in projects?

I'd like to have BitBucket mirror the folder structure I have on my desktop. E.g. I have an "archive" folder containing a bunch of repos of old projects that I keep for reference. I want them available, but I don't want them to pollute my flat view

[texmate-admin]

@Patrick Wolf - Atlassian  "Workspaces contain Projects and Projects contain Repos". Could you please verify that this is a strict hierarchy (ie: tree or container relationship)?  Either way, super important to be clear about this. Because it's not at all obvious from the UI -- Project and Workspace could just be some tagging arrangement.  There should be clear docs showing this, and also exactly what properties (aka settings) can be applied at each level. (Maybe there are such docs, but I haven't found them.)

[texmate-admin]

@Patrick Wolf - Atlassian  The current Bitbucket user's home page UI completely fails to encourage understanding of Workspaces and Projects. The left-nav >"Repositories" item loads a list of items showing repos, and that list cannot be ordered by Workspace/Project, essentially neutering the power of having such a hierarchy. Then the left-nav > Projects item loads a list of Projects, with no indication of the Workspaces they belong to. And apparently a bunch of "Untitled project" items have been auto-created, which makes this display utterly useless and confusing (due to no indication of Workspace). Finally, in that left nav panel, there's no item that would list Workspaces.  In short, as it stands, the Bitbucket UI is a shambles that's barely related to underlying Workspaces > Projects > Repos that you're trying to gain acceptance for. 

[Andy Burgess]

@Patrick Wolf - Atlassian you mentioned that projects will get 'new features for projects to make them much more powerful such as: project settings, project permissions, project dashboards'. Is there any update on this?
I think it would be really useful for my projects. Is there a EAP or anything my workspace could join?

[Richard Quadling]

As a native English speaker (and so I worry about those who are NOT native speakers of English), the phrase "Keep this workspace private", in conjunction with a single checkbox, on the main page for a BitBucket setup is extremely ambiguous.

To me, it implies that the current state of the workspace IS private, and unless I tick the checkbox, at some undetermined time, it will become non private, not necessarily public as that is not explained, but I'll certainly allow that as a reasonable expectation.

As my workspace has been in place for several years, and who really goes into checking every single detail of the account at a frequency by which any sort of privacy change would be known, I am worried that the workspace will no longer be private and the possibility that new workspaces will be created in a public manner and so allow public access to intellectual property, trade secrets, or other privileged information.

Please can you thoroughly explain this option, how ticking or unticking will affect pre-existing workspaces, as compared to a brand new workspace.