Live data from Hacker News

Announcing new tools, forums, and features

github.com

181–190 of 282 posts

Re: Announcing new tools, forums, and features

#181

I’m not sure if the name “project” is a good choice here. For one, GitHub still has some pages that refer to the idea of creating projects on GitHub, except those aren’t referring to these new kinds of “projects” (they actually are referring to new repositories or new accounts or something). And, there are literally over a million repositories that have the name Project or Project somewhere in their name[1] so you ca…

I agree, Projects is a poor choice, in my opinion.

Some alternatives that randomly come to mind: "Boards", "Plan", "Plans", "Tasks".

Re: Announcing new tools, forums, and features

#182

Some nice improvements here. It appears, though, that Projects suffer from the same problem we've had with Issues: they are limited to one repo. I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo. I would love to see projects/milestones become more capable when dealing with cross-repo issues…

This. There are fewer and fewer places for single repository applications in this day and age: We break out a repo for everything to our DDL / Stored procedures and of course our API vs. Front-end code.

It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.

Re: Announcing new tools, forums, and features

#183
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 ;)

Re: Announcing new tools, forums, and features

#184

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 b…

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.

Re: Announcing new tools, forums, and features

#185

Earlier quoted context omitted.

> Open source* The Enterprise edition features[1] are closed source, and these aren't strictly "enterprise-y" features like SAML authentication. It includes plenty of "basic" workflow features found on GitHub: - Rebase merge requests before merge - Use fast-forward merges when possible - Create templates for issues and merge requests - Display merge request status for builds on Jenkins CI [1] https://about.gitlab.com…

So what, some advanced features are enterprise only... They have to make money after all. The 'basic' product (which is far more than basic) is open source though, which incredible.

There are 100% open source products out there, and I think it's worth distinguishing that GitLab is not one of them (as a GitLab employee adds elsewhere, it's "Open Core").

I'm not criticizing the product – they're welcome to open or not open source whatever they like. I'm just clarifying the description the parent used.

Re: Announcing new tools, forums, and features

#186
post #97

Earlier quoted context omitted.

Take a look at Phabricator. It's a former Facebook project and been battle-tested at very large companies for years now. Huge open source projects like Blender, Haskell, Wikimedia and LLVM use it since it's the best open source code review tool and issue tracker. Wikimedia had a lengthy decision process and thoroughly vetted the alternatives. It has many enterprise features including code ownership, issue templates,…

I used Phabricator at a former employer, and it was one of the best software tools I've used. I'm always flabbergasted that it doesn't have more mindshare, especially when it's used internally at Facebook.

it's either self-hosted or at least $20/user/month. This alone makes it a bit of a hard ask for smaller companies at first, even for just kicking the tires.

Re: Announcing new tools, forums, and features

#187
post #97

Earlier quoted context omitted.

> Open source* The Enterprise edition features[1] are closed source, and these aren't strictly "enterprise-y" features like SAML authentication. It includes plenty of "basic" workflow features found on GitHub: - Rebase merge requests before merge - Use fast-forward merges when possible - Create templates for issues and merge requests - Display merge request status for builds on Jenkins CI [1] https://about.gitlab.com…

Take a look at Phabricator. It's a former Facebook project and been battle-tested at very large companies for years now. Huge open source projects like Blender, Haskell, Wikimedia and LLVM use it since it's the best open source code review tool and issue tracker. Wikimedia had a lengthy decision process and thoroughly vetted the alternatives. It has many enterprise features including code ownership, issue templates,…

Phabricator is also pretty amusing in terms of UX (by default), which is helpful when dealing with things that tend to anger folks -- like spirited reviews. I've often wondered if the sense of humor is half fun, half intentional in terms of psychologically making tedious work better for all involved. Even if accidental it's a nice thought.

Based on my experience, Phabricator has some quirks but is quite solid, and the well-designed command line arc workflow would please folks who refuse to open a Web browser.

Re: Announcing new tools, forums, and features

#188
post #103

Some nice improvements here. It appears, though, that Projects suffer from the same problem we've had with Issues: they are limited to one repo. I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo. I would love to see projects/milestones become more capable when dealing with cross-repo issues…

Phabricator has the right approach here. Issues and projects are global and not bound to a single repository. In my experience, this is the only approach that works in a company. JIRA does the same thing. It's the closest to a fully open source Atlassian suite that you get. Phabricator has code review, repository hosting, project management and even a CI tool.

I've seen a few projects use Phabricator, but I can't seem to understand how to use it.

Github's issues, despite it's flaws, is easy enough that non-programmers can use it. Phabricator is complicated enough that it's actually caused me to not report a bug at one point.

Re: Announcing new tools, forums, and features

#189
If anybody from GitHub is here, I have a feedback on the new Reviews feature.

When the Review approval is missing or required, please make it clear in the "Pull Requests" list-view by updating the color of the little dot and it's popup description.

Right now the colored dot and its description are only including "Checks" but not "Reviews". It would be nice to have a clear indicator of which Pull Requests are missing a review just by looking at the list.

Re: Announcing new tools, forums, and features

#190

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 b…

I agree that putting projects under repositories looks counterintuitive. In BitBucket you have multiple repositories under one project 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, 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

Post reply on HN