8 ms·

This is the example of how hard it can be for companies, especially successful companies, to alter their course even slightly. Github success was about making

This is the example of how hard it can be for companies, especially successful companies, to alter their course even slightly. Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository. This is backward. A project is a way to group resources to achieve a predefined goal. Those resources include multiple people, multiple issues and multiple repositories. Sticking a project under a repository makes no sense. In fact, a code repository in most organizations is a fairly small and an insignificant asset, just another way to organize code, i.e. function -> module -> directory -> repository, etc. It's quite awkward to think of what your company is doing in terms of repositories, so anything Github adds to repos feels out of place by default. Another example of repository-centric thinking is the homepage of https://github.com https://github.com itself when a user is logged in. It's the most important page of all, yet nothing on it has any relevance to me: just a list of people I like starring random repos. Same thing for the organization home page, just a list of repos, again. The Project idea is great. It had the potential to solve all of these issues by giving me a tool to organize digital assets in a way that's important to me. But sticking it under a repository killed it. [EDIT] It's easy to be me and be posting a comment like this, telling successful people what to do. But it's enormously hard to have a large team of PMs, developers and designers, all of whom are smart and ambitious individuals, to actually do something that falls outside of the settled way of doing things. Kudos to Github founders and employees for getting it this far and congratulations on dealing with big company problems ;)

Myrmornis 10y ago
Although there will still be lots of projects (e.g. `an open source project with one repo`, `some company with a huge monolithic repo`) that will be able to use per-repo Projects profitably. But yes, someone, please make something that kills JIRA as soon as possible.
- brandur 10y ago
  I think they could iterate on this to a place where projects are repository-specific, but still useful for high-level organization and planning. For example, if they allowed repo projects to reference issues in other repos, that would you get you 99% of the way there. You could start a single meta-repository that referenced as many repo-specific issues as you cared to consider.
sytse 10y ago
I agree that putting projects under repositories looks counterintuitive. In BitBucket you have multiple repositories under one project https://confluence.atlassian.com/bitbucket/projects-792497956.html https://confluence.atlassian.com/bitbucket/projects-79249795... We at GitLab are trying to keep it simple by having only one repository, one wiki, one issue tracker, one CD pipeline, and one set of milestones per project. Projects always below to a group. We aggregate on the group level, for example issues https://gitlab.com/groups/gitlab-org/issues https://gitlab.com/groups/gitlab-org/issues, merge requests https://gitlab.com/groups/gitlab-org/merge_requests https://gitlab.com/groups/gitlab-org/merge_requests and milestones https://docs.gitlab.com/ce/workflow/milestones.html#groups-and-milestones https://docs.gitlab.com/ce/workflow/milestones.html#groups-a... There are several things we're still considering to solve this problem better, comments are very welcome: 1. Multi project pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/17069 https://gitlab.com/gitlab-org/gitlab-ce/issues/17069 2. Group level issue boards https://gitlab.com/gitlab-org/gitlab-ee/issues/928 https://gitlab.com/gitlab-org/gitlab-ee/issues/928 3. Nested groups https://gitlab.com/gitlab-org/gitlab-ce/issues/2772 https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
- bhldr 10y ago
  Enough with the ads here.
  - luan42 10y ago
    "Gitlab CEO here"
- tyre 10y ago
  Meta-comment: As a founder and engineer, I used to give a lot of shit to Social Media as a growth channel. GitLab staff are "on point" by commenting on anything relevant to their industry (code creation/management) where their target customers are (HN). To other founders, this is what good marketing looks like.
  - sytse 10y ago
    Thanks Chris. It is a tricky balance not being too noisy (I understand the sentiment of https://news.ycombinator.com/item?id=12502468 https://news.ycombinator.com/item?id=12502468 ) but I tried to add to the conversation by by sharing our thoughts about the project <=> repo dilemma.
terda12 10y ago
I disagree, I have zero problems with these new features, which cost no extra money to me. These are all extra features, that I can choose to use or not use, that github rolled out for its users. I personally treat repositories as a single self contained code project, and I find that a lot of other people do too. The home page makes me feel less lonely. It's all good for me. Yeah a repo-centric trello board won't serve a whole corporation, but is it really that important? Github isn't trying to kill trello.com, it's just rolling out a nice little feature that the average hacker appreciates. I can see how a bigger team would lump multiple repos under one project but for that why not just use trello.com, after all it's a specialized tool created for such a task.
- supercoder 10y ago
  They definitely cost you money if you're paying for the product. Otherwise if they weren't developing new things they could lower the price
hellcow 10y ago
You've summarized my thoughts perfectly. Projects often span multiple repos. I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.
luikore 10y ago
One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?
- kareemm 10y ago
  > One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager. A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.
  - TeMPOraL 10y ago
    I think such cases call for a more professional / serious project management tool. I mean, GitHub projects is just a webapp, one that lets you move some rectangles around with a mouse. I'll be happily using it to manage issues on my small open-source projects (that incidentally are usually self-contained within a single repo), but for anything bigger / more serious, I'd rather use an external tool.
  - luikore 10y ago
    I suggest you use one repo with sub directories, one directory for API part, one directory for front end part, one for the server part ... Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together. And your problem of searching for issues assigned to one person across multiple repos is not a problem any more. There are already many good examples of managing multiple modules inside one repo: https://github.com/apache/thrift https://github.com/apache/thrift https://github.com/rails/rails https://github.com/rails/rails
echelon 10y ago
Unless you're a large company. Then you have a monorepo.
twitterdawg 10y ago
Have feedback on this post? Let @github know on Twitter.

Myrmornis 10y ago

Although there will still be lots of projects (e.g. `an open source project with one repo`, `some company with a huge monolithic repo`) that will be able to use per-repo Projects profitably. But yes, someone, please make something that kills JIRA as soon as possible.

brandur 10y ago
I think they could iterate on this to a place where projects are repository-specific, but still useful for high-level organization and planning. For example, if they allowed repo projects to reference issues in other repos, that would you get you 99% of the way there. You could start a single meta-repository that referenced as many repo-specific issues as you cared to consider.

sytse 10y ago

I agree that putting projects under repositories looks counterintuitive. In BitBucket you have multiple repositories under one project https://confluence.atlassian.com/bitbucket/projects-792497956.html https://confluence.atlassian.com/bitbucket/projects-79249795... We at GitLab are trying to keep it simple by having only one repository, one wiki, one issue tracker, one CD pipeline, and one set of milestones per project. Projects always below to a group. We aggregate on the group level, for example issues https://gitlab.com/groups/gitlab-org/issues https://gitlab.com/groups/gitlab-org/issues, merge requests https://gitlab.com/groups/gitlab-org/merge_requests https://gitlab.com/groups/gitlab-org/merge_requests and milestones https://docs.gitlab.com/ce/workflow/milestones.html#groups-and-milestones https://docs.gitlab.com/ce/workflow/milestones.html#groups-a... There are several things we're still considering to solve this problem better, comments are very welcome: 1. Multi project pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/17069 https://gitlab.com/gitlab-org/gitlab-ce/issues/17069 2. Group level issue boards https://gitlab.com/gitlab-org/gitlab-ee/issues/928 https://gitlab.com/gitlab-org/gitlab-ee/issues/928 3. Nested groups https://gitlab.com/gitlab-org/gitlab-ce/issues/2772 https://gitlab.com/gitlab-org/gitlab-ce/issues/2772

bhldr 10y ago
Enough with the ads here.
- luan42 10y ago
  "Gitlab CEO here"
tyre 10y ago
Meta-comment: As a founder and engineer, I used to give a lot of shit to Social Media as a growth channel. GitLab staff are "on point" by commenting on anything relevant to their industry (code creation/management) where their target customers are (HN). To other founders, this is what good marketing looks like.
- sytse 10y ago
  Thanks Chris. It is a tricky balance not being too noisy (I understand the sentiment of https://news.ycombinator.com/item?id=12502468 https://news.ycombinator.com/item?id=12502468 ) but I tried to add to the conversation by by sharing our thoughts about the project <=> repo dilemma.

terda12 10y ago

I disagree, I have zero problems with these new features, which cost no extra money to me. These are all extra features, that I can choose to use or not use, that github rolled out for its users. I personally treat repositories as a single self contained code project, and I find that a lot of other people do too. The home page makes me feel less lonely. It's all good for me. Yeah a repo-centric trello board won't serve a whole corporation, but is it really that important? Github isn't trying to kill trello.com, it's just rolling out a nice little feature that the average hacker appreciates. I can see how a bigger team would lump multiple repos under one project but for that why not just use trello.com, after all it's a specialized tool created for such a task.

supercoder 10y ago
They definitely cost you money if you're paying for the product. Otherwise if they weren't developing new things they could lower the price

hellcow 10y ago

You've summarized my thoughts perfectly. Projects often span multiple repos. I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.

luikore 10y ago

One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?

kareemm 10y ago
> One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry. I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager. A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.
- TeMPOraL 10y ago
  I think such cases call for a more professional / serious project management tool. I mean, GitHub projects is just a webapp, one that lets you move some rectangles around with a mouse. I'll be happily using it to manage issues on my small open-source projects (that incidentally are usually self-contained within a single repo), but for anything bigger / more serious, I'd rather use an external tool.
- luikore 10y ago
  I suggest you use one repo with sub directories, one directory for API part, one directory for front end part, one for the server part ... Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together. And your problem of searching for issues assigned to one person across multiple repos is not a problem any more. There are already many good examples of managing multiple modules inside one repo: https://github.com/apache/thrift https://github.com/apache/thrift https://github.com/rails/rails https://github.com/rails/rails

echelon 10y ago

Unless you're a large company. Then you have a monorepo.

twitterdawg 10y ago

Have feedback on this post? Let @github know on Twitter.