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 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 ;)
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, merge requests https://gitlab.com/groups/gitlab-org/merge_requests 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
2. Group level issue boards https://gitlab.com/gitlab-org/gitlab-ee/issues/928
3. Nested groups https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
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.
Hope you can keep it up! :)
But the facts are such:
1) GitLab is a YCombinator incubated company.
2) GitLab and GitHub are direct competitors
3) It's almost always relevant to the discussion, in this case; "How could it be done differently, how /has/ it been done differently"
In this case I think it's fair to bring up the direct comparison of github and gitlab. The only thing I would say could improve the situation was having github representation on here too.
If this is how all marketing would always look like, I wouldn't hate it like I now do.
Of course it fits with the model of an open source company, but it still makes me skeptical intuitively. (I say this less as a criticism and more as feedback on how one random HN user perceives their presence.)
I release computer games, which are developed largely in secret and when they hit the market after 4-7 years people find all kinds of warts and issues that we never even thought of.
GitLab seems to be of the idea, "ask people what they need, make small incremental movements into making that happen and release those increments often so that people don't get jarred by changes"
I can support that, and I don't think it bears negatively on their integrity.
What bugs me a bit is mostly the constant presence on the Hacker News forum, with this somewhat aimlessly customer-pleasing tone: "What can we do better? How can we improve your experience?" etc.
It seems like a premeditated PR/marketing strategy, which might be working well, but it's still off-putting to me.
Have we reached a point where all pleasing tones are considered marketing and PR? That we distrust people for acting earnestly?
It's in gitlabs best interests to be a superior product, right now they're an underdog, and their ubiquity on hackernews is not a coincidence, they're a YCombinator backed start-up.
Talking directly to people tends to focus the conversation too much without allowing outside perspective, you might want all of gitlab to be focused on CI, but I may think a casual CI integration would be more reasonable and likely a good solution is a middle ground- also, who do you ask? people rarely talk about their VCS unless it's relevant to discussion.
Asking the community for opinions is a great thing to do - you might get some good suggestions and the community then feel valued. That doesn't mean you need to do exactly what the community tells you, but taking it into account in the design process may help build something that the community actually wants to use.
however, unless i'm missing something, a "project" in bitbucket is basically just a folder to group your repositories in. there's no real features associated with it. A github project is project management tools based on a repository.
If GitHub had called their feature something else, (for example, call it "the board") and nobody would be expecting it to be anything other than per-repo.
In the future you will see us adding more capabilities to projects, such as permission management  or settings on a project level, which already exist in Bitbucket Server.
E.g. I come at things from the intersection of (embedded) product line engineering and continuous integration, which leads me towards a different place than somebody coming at things from (e.g.) consulting or web services ... but it is difficult to have a meaningful discussion about the pros & cons of each approach without the language / terminology that we need.
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.
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?
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.
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:
Another one is where we have forks of libraries with minor patches to suit our needs.
Spinnaker is comprised of a bunch of quasi-independent microservices, designed to work together. I don't think it would necessarily make sense to have them all in the same repo, when they could be swapped out or even used separately in another project.
But yes, someone, please make something that kills JIRA as soon as possible.
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.