Forking collaboration model for our team is costly

[eliaw]

We use the forking model for collaboration within our team of ~7 developers. We've been using this model for around 3 years and migrated over from github. The issue we have is that in collaboration, it is often useful when reviewing a pull request to have access to the user's fork. The two most common caes cases this is valuable in our organization is:

1) You want to fetch their fork so you can test and work with their code before it is upstream.

2) You want to see the raw file. We use pull request for design docs so we can comment in-line, but without access to the user's repo, you cannot view the file in markdown format.

However, in order to make this work for our team, we have to give access to our private forks to the other developers which put us at more than 5 users accessing our private repos. This means we must not only pay for an upgraded account for the group account, but for each individual. This means to get forking model to work we have to pay (7+1)*10 = $80/mo instead of just the $10/mo for a 10 user group. So to get the forking model to work for our needs, it would be N times more costly where N is the number of developers in your organization. I don't believe this is the intention of the pricing model, but I could be wrong :P.

The solution that would help us the best on this would be to allow read access on private repos to be granted without it being counted as part of the user limit. Would love to hear thoughts around how to get the forking model to work better under the current pricing limitations as well.

[aMarcus]

For a team setup such as this, we recommend a branching model instead. This way all developers share the same repository and everyone can view all the work from everyone else. To ensure that your master branch doesn't get directly committed to, we have also created branch permissions to help you secure your production branches. Then, only designated people with write access to the branches can merge in Pull Requests. With this, you get the added benefit of all the work being in one central place.

If you remain on the forking model, we would suggest using the single team account for all forks. This way, everyone can retain access. A naming convention would help differentiate the repos from each other. Since we have no limit on the number of private repositories, this should also work for you.

[David Tapia]

This is actually a bad suggestion and evidently shows the limitations of Bitbucket in its current form, when implementing a Git forking model.  Any suggestion to change process to accommodate the product -- instead of creating flexibility in the product to accommodate the various needs of the customers -- seems to be a huge red-flag when considering the adoption of a new tool. 

There are a number of clear advantages to using the forking model over the branching model which I won't get into here, but this model seems to preclude the use of Bitbucket for the time-being.