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 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 ;)
Thanks Chris. It is a tricky balance not being too noisy (I understand the sentiment of 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.
I'm in no way affiliated with gitlab, but I do like the product.
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.
I enjoy threads like these; this is how healthy competition looks like. GitLab peoples' comments are relevant, and their discuss technical issues and merits of their solution, instead of comparing to GitHub ("we're better than the competitor!").
If this is how all marketing would always look like, I wouldn't hate it like I now do.
YMMV, but I find sytse so hugely overbearing that I actively don't want to use GitLab because I don't want to encourage what I see as tacky, bad behavior. He and other GitLab staff can do as they like, but I'm not rewarding it.
I don't have a strong opinion but my gut feeling is that the GitLab staff is always asking HN what to do, which kind of makes me question the integrity of the company's own ability to decide.
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.)
Thats fair comment, but how do you define the middle ground between sitting in an ivory tower and wondering what the next feature should be, between asking people who actually use your product in ways you wouldn't expect?
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.
I'm not sure. Maybe I would try to integrate the product suggestions into the product more, along with just reaching out to users directly and generally conducting the product in a typical open source fashion.
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.
Objectively, that's such an odd thing to be unsettled about.
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 what to do doesn't mean doing what they are asked. Turning suggestions into software features requires a lot of skillful software design and marketing work.
There's nothing wrong with deciding, among countless incompatible options, to evolve the product in ways that appears likely to increase revenue, while not seeking feedback would be an actual bad sign about GitLab's ability to decide (and improve).
That's interesting, it's not how I read their interactions at all.
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.
> In BitBucket you have multiple repositories under one project
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.
That's correct, right now projects in Bitbucket help to organise your repositories into projects. With the raise of microservices, it's quite common that a project or product is made up of many repositories.
In the future you will see us adding more capabilities to projects, such as permission management [1] or settings on a project level, which already exist in Bitbucket Server.
It would be nice if there were a taxonomy of different organisational approaches so that we could have a common terminology to discuss the pros and cons of each.
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 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.
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.
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?
> 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.
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:
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.
Reusable and reused components span multiple projects and even companies. A quite reasonable scenario is when a project includes a component library that's loosely coupled, open-sourced and used by others (so it pretty much has to be in a separate), but it's not just an included dependency but being actively worked on in a project - e.g. a single small new feature would require commits to both the library and the repository that's using it.
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.
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.
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.
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 ;)