Issues

Issue #8392 wontfix

Collaborator limit should not be imposed against forks of paid repositories

John Ruiz
created an issue

Our organization pays for your [excellent] service.

The way we want to collaborate is by having our employees fork the organization's private repository and then submit pull requests back. This allows us to use the pull request as a gateway for code review, and we really like it. It also allows us to better control our "truth" repository (limited access to master/dev branches, no dangling rotting feature branches, etc). (this is no different from the standard open-source method for collaboration)

The problem is that our employees' private forks have a collaborator limit capped at 5. If we're paying for the service, our employees shouldn't have to pay to collaborate with their teammates, even though it happens to be in their account.

We thought we might work around this by creating repositories named <REPO>-<username> for each teammate, but then we couldn't figure out how to submit pull requests because they weren't true forks.

If possible, we wanted to avoid employees working out of the truth repo day-to-day. And they shouldn't have to pay money -- because we did.

What do we do?

Comments (11)

  1. John Ruiz reporter

    Dan,

    I'll try this and let you know. But I hope that you also consider that a work-around and not a solution. This will leave us with many, MANY repositories in our organization.

  2. Dan Bennett staff

    The problem is that those separate accounts are in fact separate accounts with their own billing information. If the repos belong to the company then we can properly associate the user limit with the company's account. If it's a private repo belonging to another account we cannot identify whether that is a private project of a team to which that member belongs or simply something else. Fork origin and group membership assumptions would be just that -- assumptions. I can think of many scenarios where a user may fork another repository and the billing of that new fork should not be associated with the parent just as you have a situation where you'd like the reverse to be true.

    As an alternative, have you considered creating a single development fork under the company account and switch to a branching development model instead of a forking one? We have also recently released a branch management feature which would allow you to further reduce the repository count to one by providing a controlled "branch of truth" while still allowing developers to work on their own feature branches.

  3. John Ruiz reporter

    Dan,

    I understand your counter-argument. I told the team that you'd likely tell us to have two repositories. I think we'll go down that route in the future.

    I don't care for the single repository case for the following reason: should I need or desire to give access to an external party, I don't want to confuse them with all the feature branches; they should see "develop", "master", and all the release versions via tags. Nice and clean.

    If you want to close this issue, I have no objections.

  4. tszming

    I also come across this issue today and agree that removing the limit make sense as sometimes we need allow others to fork a private organisation's repositories for code review purpose.

  5. Daniel Cardin

    I have ran into the issue from another angle. One of my users revoked admin on his fork, meaning that as the administrator of the repo, I cannot access his fork... nor revoke it. I think there needs to be something in a fork to tie it back to the actual account for you to manage access and billing appropriately.

  6. Dan Bennett staff

    Daniel,

    That's a tough sell. Once a user forks a repository to their account they are the owner of that repo.

    Think of it from the perspective of the person doing the fork. If you forked repository X, should the owner of that repository have administrative access to whatever it is you're doing there? What if you were working on proprietary or confidential extensions? This gets even trickier if X were a public repository, or had been a public repository at the time of the fork but is now private. We sympathize with your cases but cannot see a clear path to enabling the complicated system of rules required to make such a thing work.

    This is why we encourage branching over forking for most workflows.

  7. Log in to comment