Announcing new tools, forums, and features | Hacker News Reader

Announcing new tools, forums, and features

github.com

1,142 pointsjoshmanders269 comments

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

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.

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

Enough with the ads here.

"Gitlab CEO here"

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.

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.

A willingness to engage with the community as often and as effectively as you guys have is surely not commonplace.

Hope you can keep it up! :)

I thought HN frowned on metacomments, and here it goes, talking about GitLab again, in a Github topic...

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.

If your product targets developers, commenting on HN seems like a pretty high value channel compared to something like facebook.

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.

I fully admit that I'm a cynical and cranky bastard.

At least you're polite and well-spoken.

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.

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).

> 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.

[1]https://confluence.atlassian.com/display/BitbucketServer/Usi...

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.

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

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 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.

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/rails/rails

Client/Server is one case where I think having multiple repos under one project makes a lot of sense.

Another one is where we have forks of libraries with minor patches to suit our needs.

Multiple codebases for multiple platforms also deserve multiple repositories.

Agreed. Depending on how much code is shared it could be one repo, or n+1 (n=platforms 1=shared code)

https://github.com/spinnaker

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.

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.

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

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

This is a rough summary of what all I read in the blog post:

1. projects. replaces trello, waffle.io, zenhub and many other similar services.

2. code reviews allow approval/request changes as sunny's screenshot shows

3. reviews can be made mandatory.

4. github platform integrations is getting a roadmap

5. a graphql api to query their database

6. enforce 2fa in organizations (much love for this one)

7. summarized timeline for your contibutions

Just a few days back, at the GitLab release, I'd noticed a lot of complains about gitlab releasing useful and impactful features and github being slow on releases. Moreover, now with a public roadmap (even if it is just for platforms), it is a great start.

I'm really liking this change in pace.

mods: Can we make this the canonical discussion for this topic? Otherwise, a lot of branching will happen

Doesn't look like Projects comes close to replacing ZenHub / Waffle.. Not for proper teams anyway – real project management needs to be much more robust so I'm keeping ZenHub for now.

>projects. replaces trello, waffle.io, zenhub and many other similar services.

This is really not about replacing those services, it's more about building a better foundation for integrators like Waffle and ZenHub to build on.

I'm looking at https://www.zenhub.com/product, and while it does have some extra features (filters on priority, labels), but for most people the base set provided by github is gonna be sufficient.

Sure, it won't completely replace them, but GitHub building this as a platform counts as competition.

Using ZenHub also provides additional features like time estimation, burndown charts and Epics (for issue hierarchy) - we find that for larger teams, these are must-have features to work inside GitHub.

At Waffle.io, we're all about making project management better for engineers. We believe it's awesome that GitHub is investing in this too, and we'll continue to make GitHub delicious :). More here: http://blog.waffle.io/say-hello-to-wafflebot/

At ZenHub, we have already starting working on some integrations with this functionality which you can read more about here - https://www.zenhub.com/blog/dispatches-from-github-universe/

Our focus is going to remain on how to integrate a full-featured project management suite within the GitHub eco-system. The GitHub projects release will make a great foundation, and ZenHub will be there to provide the more advanced features like issue hierarchy (epics), time estimation and reporting. Lots of exciting releases coming soon for ZenHub users :)

Except all those services have already built a foundation ...

This will inevitably force out GH's integration partners once users start to complain how feature-deficient projects are in their current state.

Founder of Zube here. GitHub Projects seems like a nice solution for very small teams, side projects and open source projects. However, serious teams need more powerful features like a well thought out workflow, support for multiple repos and burndown charts.

Shameless plug: Zube has all these things and more - https://zube.io :)

It looks like enforcing 2fa in an org (finally!) means anyone who doesn't have 2fa will be booted out (included whoever may be paying for it at the time) with an email explaining why. I'm afraid to tick the box because of this. :o/

Contact everyone, tell them they have a week, then tick the box. If they didn't do it within the week it's either not important to them or they'll add it right quick after you tick the box.

We have some "shared" users for things like bots, etc.. wonder how to deal with that since we don't want to enable MFA for them. Otherwise I'd be all over this..

This is a huge issue for us at the Linux Foundation. Infra accounts make enforcing MFA for orgs impossible

Even if I could do classes of accounts. Owners and admins, MFA required. Users (bots) that just update CI status, not required.

For CI bots I think in the future you will be able to build an "integration" instead of using a user account. From the blog post

"We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to."

https://developer.github.com/changes/2016-09-14-Integrations...

https://developer.github.com/early-access/integrations/

Also mentioned in the announcement is that bots and integrations won't need their own user accounts or to impersonate users in the (near?) future.

For bot accounts, you either generate a personal access token for that account or (probably better) use SSH.

Not so different from human users who have 2FA activated and use the command line to interact with github.

https://help.github.com/articles/providing-your-2fa-authenti...

You're right, and I'll be sending out the emails tomorrow. Thanks!

Currently, we tell every new employee on joining the org to enable it, and review it a week later to ensure that they followed through.

It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later).

I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).

The bot user probably doesn't need to actually be in your org though, convert them to outside collaborators.

I agree with you that the pick up in pace of Github's lacking features has been phenomenal, and I don't really quite understand all the love of GitLab except rooting for the underdog. Github is the clear industry leader, has been since essentially it's creation. It is very fast and feature-filled. It is the central location for the vast majority of code I use and see. Since the open letter to Github with the complaints of feature requests, they've really stepped up their game and made competitors really non-starters from my point of view.

> I don't really quite understand all the love of GitLab

- Open Source

- Free private repos

- Free self-host (edit to add "Free")

- Everything in one spot (repos, ci, review, coding environment, etc...)

> 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/features/

Use fast-forward merges when possible

GitHub (annoyingly) can't do fast-forward merges from non-squashed PRs either.

Display merge request status for builds on Jenkins CI

GitLab implements basically the same API as GitHub for updating build status of commits from external services, or do I misunderstand what feature you mean?

But in general I agree, there are some options GitLab reserved for EE that really feel like they should be part of the CE as well.

Yeah, I just chose some random features that I may have interpreted incorrectly. There are others; people can read the features page for themselves.

And FWIW, I admire GitLab for their open source work. I just think it's worth distinguishing that it's not entirely open source.

Thanks for the admiration. If there are features that people think that should belong in the open source edition we're all ears. We've done so before https://news.ycombinator.com/item?id=10931347 A feature comparison between CE and EE can be found on about.gitlab.com/features/#compare

Since I'm not sure were else to report this:

When googling for the fast-forward feature one of the top results was this GitHub thread, which had quite a bit of activity fairly recently: https://github.com/gitlabhq/gitlabhq/issues/2324

It seems like many posting there are not aware that this repository/bug tracker is not an official channel anymore -> maybe posting an automated comment in all issues with recent activity or locking them could help avoid confusion? If you arrive via search, you don't see the notice in the main repository description.

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, and a Gerrit like, sane code review workflow. You can fully integrate it with your CI tool and it even displays coverage results inline and such.

Ask me anything about it :) I'm not affiliated with it but am an experienced user.

I'm evaluating GitLab at work currently - primarily for its code review features and really like it. Read a lot about Phabricator yesterday as a possible alternative, and am considering testing it.

I wonder how it compares to GitLab. Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch? Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature? Because currently in GitLab the author does get a notification email for every line comment I make, which is also not really the perfect way of doing it.

I already know that Phabricator squashes the changes into one commit, I think I can live with that. (because it promotes small code reviews) Does Phabricator have any problems with git rebase, where I'm refreshing a feature branch with the most recent master state? What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?

Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello. Can it be used by non-developers without giving them access to the code?

Looking forward to test Phabricator tomorrow.

>Is it possible to set up protected branches, where I can say, only users X and Y are allowed to push to the master branch?

Yes. I recommend (and my employer uses) a Herald rule that admits pushes to master only if the changes are in an approved Diff (unit of code review). This way you get an enforced 2-man rule, but anyone besides the author can approve the change.

This is currently impossible with Gitlab AFAIK, and is the main reason I won't use it.

You can also configure Herald rules to add blocking reviewers to other people's Diffs based on arbitrary criteria (i.e. touches X file and it's a Tuesday). A Diff cannot be considered approved until all blocking reviewers have signed off.

Reviewers can also be groups, so you could say, for example, changes that touch Y file must be reviewed by Security, but any member of Security can sign off.

>Can I do a code review and then finalize it when I'm finished and does the author get notified with a summary like the new GitHub code review feature?

Yes, everything you do on a Diff is batched and happens all at once when you click "Submit" at the bottom. Inline comments, the free-form text box, and the action all come as one email.

> What I really like about the merge/pull request workflow of GitLab is, that multiple developers can work together on one feature branch while a merge request is open and can be used as a discussion platform for the changes - is this possible with Phabricator?

A Diff is really meant to be an individual's small, well-defined contribution. Multiple people submitting code to a one diff can get messy. This would be better modeled as many diffs.

You are allowed to land diffs against branches other than Master, however this gets messy. It is not a first-class use case. My employer does not collaborate on feature branches; instead we land half-finished features into master (and production) disabled by feature flags.

It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).

>Also I'm wondering how solid the issue tracking is, and if the project workboards can compete with Trello.

Issue tracking is totally solid, very configurable. Project workboards consist of tasks/issues, which are much more expensive to create than Trello cards: you fill out a pagelong form, pick type, severity, owning team, title, description, etc. vs just free-forming a title. However, you can drag tasks around the workboard just like Trello and it looks pretty similar.

>Can it be used by non-developers without giving them access to the code?

Yes. Permissions (and approval flows, and notification rules) are very configurable. Phabricator is well suited to a large organization with rules, but this suitability doesn't carry too much overheard.

I don't think you could collaborate on issues with customers. Nontechnical people in your company, though, totally - we do that.

> It is NOT a merge/pull-request workflow. It treats Git more like Subversion; Phabricator is a very sophisticated alternative to emailing patches around before SVN committing them (basically the equivalent of landing).

Due to popular demand, they are adding some tools to allow merge/PR workflow. That being said, it was not stable last time I checked (~6 mo. ago), and it will probably take a while, if ever, for it to be as good as what's already there for Differential (the current code-review/landing system).

That being said, their existing tools are really good, and the fact that you are not married to a single VCS is really nice. You can have some legacy SVN repositories and be fine, and use the exact same interface for code-review and landing as in your shiny new git repositories. Prefer hg to git? No problem. Have some complicated gitolite setup you don't want to bother migrating? Phabricator works fine even when not hosting the repository.

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.

It's worth noting that the first 30 days are free, and all 3 source control systems it offers have fairly painless synchronization, so there's low risk IMO.

On top of that it was really painless to install locally. I had it setup in under an hour, and that included my first time ever setting up my webserver with php, and first time configuring a mysql instance.

I haven't seen it running yet, but just from reading the features page, I'm already a fan

https://www.phacility.com/phabricator/

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.

Even the configuration option for turning that off is amusing ("Serious Business" IIRC)

Phabricator is awesome. It felt like it was more for experienced developers or larger organizations when I was using it(in a good way). Something to consider depending on your team.

FreeBSD has been using it too for a few years now. https://reviews.freebsd.org

To make sure there is no confusion we now refer to ourselves as open core https://about.gitlab.com/about/#stewardship

I want to echo here what I said in https://news.ycombinator.com/item?id=12501271 "If there are features that people think that should belong in the open source edition we're all ears. We've done so before https://news.ycombinator.com/item?id=10931347 A feature comparison between CE and EE can be found on about.gitlab.com/features/#compare "

Regarding the examples please help me understand:

1. Can you rebase in the GitHub interface?

2. Does GitHub have an option to fast forward merges?

3. Please let me know if this is a feature people want open sourced. EDIT turns out that this is part of the open source edition already https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/cont... I created https://gitlab.com/gitlab-org/gitlab-ce/issues/22185 to update the docs

4. We have a commit status API in GitLab CE https://docs.gitlab.com/ce/api/commits.html#commit-status and works with the open source https://github.com/jenkinsci/gitlab-plugin We do have additional integration in EE https://docs.gitlab.com/ee/integration/jenkins.html

BTW you might be happy to learn that what you mention as an example of typical "enterprise-y" feature is available in GitLab CE https://docs.gitlab.com/ce/integration/saml.html

> 1. Can you rebase in the GitHub interface?

> 2. Does GitHub have an option to fast forward merges?

So is Gitlab's aim to just play catchup to Github?

We already have these features, we just opted to make them EE/.com only since we think they are more relevant for organizations that have more than 100 potential users.

We have a broader scope than GitHub, see our announcement broadcasted on Tuesday for more information and a demo https://about.gitlab.com/2016/09/14/gitlab-live-event-recap/

are you joking? it's the other way around. github is only just now playing catch up to gitlab

GitLab has had a larger feature set than GitHub for a long time now.

Github compromises by having a nice ecosystem of tools which you can plug in, but having it built in is always nice since the integration is tighter.

So, when reading the features page, I was considering 1 and 2 in terms of a feature that I use at GitHub religiously: squashed pull requests (that are automatically fast-forwarded) [1].

If I'm reading this correctly, this exists in GitLab as an enterprise feature, so I think my earlier comment isn't too far off. There also appears to be some community feedback suggesting this should be a CE feature [2].

[1] https://help.github.com/articles/about-pull-request-merges/ [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/4106

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.

It's only kind of open source, and only partly. They call it open core, so saying open source outright is a bit misleading.

The review feature is very new in GL, and that plus all of the things you are mentioning within "everything in one spot" is available in this update (except maybe the coding env, not sure what that means anyway), if you've read the announcement. Github also has self hosting.

> It's only kind of open source, and only partly

CE is a very large subset of EE. But yeah, maybe "open core" is a better term.

> except maybe the coding env, not sure what that means anyway

Koding integration (I haven't tried it yet) https://about.gitlab.com/2016/07/26/koding-and-gitlab-integr...

> if you've read the announcement

I assume you meant Github's announced features? Yeah, I think they're great.

> Github also has self hosting.

Costs $, Gitlab has free self hosting (updated parent comment)

Where can I find a link about self hosted Github? Just curious to read about it.

It's github enterprise: https://enterprise.github.com/features#pricing

Thanks. I was unaware this existed. Looks like it was launched in 2011[1]. Somehow I thought that with their (presumably, from what little I've gathered over the years) complex infrastructure setup this would be hard or impossible. I wonder if they have an Enterprise team devoted to keeping up with a SaaS mainline and how much work they have to do, or if they made/make some decisions that make this (Enterprise) a fairly self-contained "it just works" sort of thing.

[1] https://github.com/blog/978-introducing-github-enterprise

Hi there - GitHub Enterprise definitely has a devoted team focused on building features tailored to the needs of customers requiring/requesting an on-premise solution, as well as making it entirely self-contained. We typically release a new version of GitHub Enterprise on a quarterly basis - you can see the latest additions we shipped with GitHub Enterprise 2.7 here: https://enterprise.github.com/releases/2.7.0/notes

We have companies scaling their GitHub Enterprise instance up to 25,000 users, and we also have a dedicated Enterprise Support team available 24/5 to resolve any technical issues.

Thanks for the answer straight from the horse's mouth! I'd often heard about companies storing their code on GH and didn't understand how they could get away with using a SaaS app available on a public cloud; now I know, they can just run a self-hosted version on their own private network.

I am not your target market, FWIW, but just a curious developer.

No worries - glad to provide the additional details!

We also recognize that having a SaaS solution like GitHub Organizations meets the needs of many companies (over 75,000 at last count), and our announcement of 2FA enhancements today is an indication of our desire to continue that approach.

> It's only kind of open source, and only partly.

That's a pretty misleading characterisation. You can browse the source code, submit issues, see what's being worked on, contribute PRs, and freely download and run your own instance of GitLab. A handful of enterprise features aren't open sourced.

GitHub in contrast is a black box.

I agree that it is better to call ourselves an open core company and our website and communication should reflect that https://about.gitlab.com/about/#stewardship If we're still using open source to refer to the organization somewhere please let me know.

We've had code review for many years now in GitLab. The coding env probably refers to our integration with Koding, an online IDE https://about.gitlab.com/2016/07/26/koding-and-gitlab-integr...

Github Enterprise (their self hosted version) is quite expensive.

> I don't really quite understand all the love of GitLab except rooting for the underdog.

and self-hosting :-)

github has self-hosting. It is a little pricey but that is not a product differentiator.

Price isn't a product differentiator?

The feature isn't a product differentiator.

If I had unlimited money, I could hire an army of coders to write me a git platform with all the features I want, and host it on all the servers, everywhere. It's simply not feasible to talk about product features in a vacuum without considering the costs.

Price is a feature.

No-one said it was.

But the answer of self-hosting is a perfectly valid answer for "Why the love for GitLab?" when one = $0 in licensing, and the other = > $2,500/year in licensing.

Plus, not too long ago, GitHub restricted the number of free private repositories, for users and educational organizations. Although they offered educational plans for labs, it still had its limitations. Thus, free self-hosting was what attracted us to use GitLab in our lab.

> No-one said it was.

That is literally what the comment I replied to said. That "self hosting" was a reason to root for gitlab.

"Reason to root for GitLab" does not necessarily equal "product differentiator".

Similar to the "you can't use price to differentiate the two" - why not?

so basically, you like it because it's free.

doesn't speak well for their business prospects.

Actually, we pay for GitLab EE.

GitLab's pricing model won a lot of people when GitHub's was ugly for anyone who wanted private repos (single guy at home with 10+ private repos for things like your dot files, etc? $20+ a month, for what likely amounted to under 1MB of disk space).

Ok, so change "free" to "cheaper", and the point remains: you like it because they charge less.

Still, most people in HN threads use it because it's free. Which is great for an open source tool, but bad for an unprofitable, VC-funded startup.

If I can only afford one, then the price is definitely a differentiator.

Github has self hosting too right?

Not for free.

> It is the central location for the vast majority of code I use and see.

And that’s exactly why you shouldn’t use it.

> Since the open letter to Github with the complaints of feature requests,

This, and the answer from GitLab to that letter, is what made GitHub move in the first place.

You need competition for a healthy market.

Here is some more competition in the form of a modular integrated tool 100% libre and open source. With a single instance of Tuleap you can have per project wildly different configurations. One project can have a scrum dashboard with GIT and pull requests, while another can be kanban and SVN with Jenkins CI, and a third could even be setup as Waterfall with CVS or other combinations.

Issue tracking, or anything tracking really, document versioning and templates to get you started really quickly. It’s proven scalable as it’s already used by companies with more than 17 000 users with a single instance of Tuleap. I would love some feedback as we are actively developing it with monthly releases. You can check it out at https://tuleap.org/

As well as the sibling comments here, one could also argue Gitlab deserves at least partial credit for motivating this pick up in pace.

I think it was more the open letter to Github, which motivated both Github and GitLab (seen as an opportunity to compete).

GitLab's roadmap yesterday surely didn't motivate or spawn the "New GitHub Universe," and I wouldn't think that Github is very nervous about GitLab currently due to it's massive lead in the market. Maybe this new round of funding made some of the folks at Github look over at Gitlab, but I doubt too much else.

> I wouldn't think that Github is very nervous about GitLab

Just my 2 cents, but I think they very well should be

At least it puts a ceiling on what GitHub will be able to charge since from now on, they will likely ping pong on features.

> massive lead in the market

Ehh... dominance among open source projects, and Hacker News and Reddit thread cool points, is one thing. But in boring old terms of actually making money, how IS GitHub doing?

"Enterprise" is practically a swear word here, but that's where the meaningful paying customers are. From my anecdotal experience, Atlassian absolutely dwarfs GitHub in the enterprise world... and that's just the enterprises that are willing to host code in the cloud to begin with.

For large shops demanding an on-prem solution, GitLab seems to have a much better story than GitHub since that's really their business model bread-and-butter. For GitLab, the cloud hosting is basically just a marketing tool.

They're doing quite well, and have been pretty much since the beginning.

https://www.quora.com/How-close-is-GitHub-to-returning-to-pr...

https://signalvnoise.com/posts/2486-bootstrapped-profitable-...

http://www.businessinsider.com/github-is-now-worth-2-billion...

It's historically been tough to compare them to Atlassian because Atlassian has provided tons of other enterprise services like Jira and Confluence, and an 8 year lead plus going public, but I think Github is definitely working on better squeezing into the enterprise space with this current announcement.

> "Enterprise" is practically a swear word here, but that's where the meaningful paying customers are. From my anecdotal experience, Atlassian absolutely dwarfs GitHub in the enterprise world... and that's just the enterprises that are willing to host code in the cloud to begin with.

I was recently at an F1000 company and we did self-hosted GitHub Enterprise. While many services were duplicated across departments, there were a variety of other commercial VCS setups, and our GH was not highly available… there was a ton of buy-in to GitHub Enterprise. And, yeah, we did JIRA and Confluence (and SharePoint…).

I'm doing a gig for a F100 company now and, well, we've got GitLab. I dunno if I'm just more used to GitHub or if I actually prefer it to GitLab.

At a small company here, and we moved from GitHub to BitBucket because both the pricing (a couple dozen private repos) and user-management were more friendly. User management is one of those things people hand-wave away until they're the poor sap who has to manage it.

Then be a fan of of GitLab for putting the fear of competition back into GitHub ;)

(It's of course not certain they are the reason they are moving again, but GitHub looked a lot like the market leader that feels like it doesn't have to bother much anymore. And they weren't entirely wrong.)

built in CI integration is a huge draw. There are also a nontrivial amount of companies that refuse to let source code "out of the building" so they need to self host, either for real reasons or perceived.

Very fast? Maybe in the US, but rest of the world still has oceans in between of them. Adding 200msec+ of latency to every request makes it feel very sluggish.

Maybe they should start looking into global rollout like Google, Facebook and basically every serious company having world-wide audience.

Sure, but compare the speed to Gitlab since we are on the topic.

I think particularly here on HN, I've seen a good deal of concern over github's social agenda and the perception that they've hired a lot of non-engineering folks to push that agenda.

I've only seen that among members of the alt-right.

The alt-right is apparently everyone's favorite new boogeyman for use in thought-free dismissal

It's always disappointing to see a self-described intellectual community give over so heavily to such an obviously broken thought process, but humans being the emotionally manipulable creatures they are, it makes sense.

IMO:

A lot of people seems to think they are smart because they belong to a powerful or politically correct group.

Also a lot of people seems to think they are smart because they are rooting for the underdog or just plain contrarian. ; )

This all seems like baby stuff compared to Atlassian though. JIRA, Confluence, Bitbucket, HipChat. That's hard to beat.

> baby stuff

JIRA doesn't support markdown. That seems like baby stuff to me.

It does. For years.

If Atlassian's competition is baby stuff, give me a pacifier and a bottle.

re: enforced 2FA, it does not appear to play well with bot accounts -- it's either all on or all off, and bots don't count as using 2FA.

I thought the stuff about Github's pace was funny too. People have short memories, I guess.

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.

Take a look at ZenHub [1] - it lets you stay inside GitHub, but adds much more full-featured project management capabilities including multi-repo boards and advanced reporting features like estimates, issue hierarchy (epics), personal to-dos, burndown and velocity charts, etc.

[1] https://www.zenhub.com

At Goldbely, our solution has been to have a single GitHub repo that's just for issues and use tags to highlight the actual code repos involved.

Works pretty well, if a little awkward at first.

We do this as well at Purple [0]. It does make issue referencing in commit messages a bit unwieldy; you have to include the full path to the issue (e.g., org-name/repo-name#34).

[0] - http://purpleapp.com

Yup! Using Projects will force us to maintain multiple projects for one single "real" project, as our code is split across multiple repositories. (Web app, desktop client, infrastructure, company issues, etc)

I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.

This has been why we don't use github's issues, wikis, and why we won't use their projects. For example if the overall product has a web site repo, server repo, iOS repo and an Android repo then they need to be used as a coherent whole. An issue might be reported against iOS but the cause is in the server, so the ticket would need to be moved. Rinse and repeat for all the other interactions of piece, and that collaborators often don't know (and shouldn't need to) precisely what issues, wikis etc correspond to which repo.

The now defunct Google Code had a very good solution for this. You could create additional "sub" repositories alongside the "main" one. Github already does that for the wiki, but doesn't generalise it to allowing additional ones. I'm somewhat convinced this is because github has the whole "charge by the repository" model, which is at odds for being useful for projects that require multiple git level repos.

They recently added a per-user pricing model, so maybe they would be open to suggestions.

It would require fairly extensive changes on how they do things under the hood. Google used suffixes - eg you checked out the wiki as github.com/org/projectX.wiki and could create a git repo like github.com/org/projectX.android

I would put all projects under one repo as orphan branches. With some branch-naming conventions you can easily separate those.

Just no.

Imagine you just hired a new web developer, and added him to this repo. His first local repo clone will include 3 entire projects for iOS, Android, and backend server, that he has no use for, or should even have permissions to access in the first place.

This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.

So companies like Fb (with their gazillions of files) can afford a single repo and you hiring a new developer cannot?

I loathe orphan branches with an intensity that could produce a nation of orphaned children.

My view is: unless you have an inescapable security, physical or performance reason not to have a single repo, have a single repo.

Directories are for managing directories.

Version branches are for managing versions.

They are not the same thing.

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.

Codetree [1] addresses the multi-repo issues problem you mention, we roll up as many repos as you want under one 'project' which you can view in either table or kanban board style.

We also add a host of project management functionality on top of GitHub issues like advanced filtering/sorting, dependency tracking, and the ability to setup your own dev/release workflow.

[1] https://codetree.com

Thanks for providing the feedback here - I've passed it along to the Engineering team building out Projects.

I'm curious as to whether you are dogfooding Projects, especially when feature work spans multiple repos. If so a "how Github uses Projects" tutorial may be worth considering.

Indeed, many teams are - the original iteration of Projects was released to staff a few months ago (as is common with many of our product releases), so we're continuing to learn how teams are using it most effectively. Yesterday's release to the public will help with that effort too.

I personally use it on my team at the moment - it's been pretty useful and we've passed along frequent feedback to the platform team responsible for it.

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.

For what it's worth, I've had success browsing issues accross repos using the https://github.com/issues page. E.g. to view all issues that are in both redux and react-redux:

https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...

I'll be curious to see if they've made API granularity more sane.

We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing should need).

This is an important part of the new integrations early access program: https://developer.github.com/changes/2016-09-14-Integrations...

Plus a million - I'm not sure how this still isn't a feature.

Considering all of the PCI-DSS / HIPAA / SOX / etc. audit points around change control (even ignoring corporate versions of the same) it's practically impossible to add external services to GH and have them be useful while still meeting compliance. Change control is required, but that also implies control of change control. As-is any service could delete all of your content, whether intentionally or inadvertently, or even worse could corrupt or otherwise alter your history.

It may be detectable and recoverable because git, but it would be infinitely easier to have code and PR be r--rw-.

EDIT: This is now a thing, according to @bhuga below. Also, GH is now publishing a roadmap for what's coming down the pipe, so we're not in the dark as to when these critically-important-why-isnt-it-out-yet features are being worked on. https://developer.github.com/early-access/platform-roadmap/

WakaTime has been bitten by this lack of granularity too... it hurts integration usage when we ask for code access when we only need commit log messages.

I can't even get permission to read from private repos without also requesting write access to the user's entire codebase on GitHub. I don't want that power.

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 can now create projects within things that are already called Projects (except the “projects” act more like issues, or tasks, or something).

Naming is important, there’s a reason why engineers devote so much time to it.

[1] https://github.com/search?p=1&q=project&type=Repositories&ut...

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

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

Impressive. I have to think that this is all competition fostered by Gitlab - all those features were present in Gitlab. Competition at work :)

I have been a huge pusher for GitLab, and my basic reasoning was that GitHub isn't open sourced like GitLab. GitHub was going awfully slow and no communication to its customers in new features. Looks like GitLab lit a fire underneath them. I wonder which one is "better". Nevertheless, at least there is competition now. SCM is the biggest component in any coding practices, I'm that it is finally getting attention.

Hopefully the community forum will help GitHub to keep in touch with the community!

There's some nice stuff here -- probably some of it that I'll use -- but most of this is targeted at organisations (and in particular, managers and administrators) rather than individual developers.

Understandable -- it's clearly companies that are paying the bills these days -- but a little disappointing given the extent to which GitHub got big by attracting lone hackers and little open source projects.

If somebody else manages to claim the small-scale end if the market it could eventually spell trouble for GitHub.

This isn't a random shift in direction for github... in the end it will make the platform so complex and irrelevant for open source teams that they will go elsewhere. I wrote an analysis of this shift some time back: http://hintjens.com/blog:111

Why? These features don't change the individual experience at all. You're not forced to use them.

The review stuff is semi similar to what I requested GitLab do and I'm surprised it's taken so long for anyone to really do it. It's a great workflow. I'm still not convinced about keeping all of your project's management in the version control system (I mean I prefer issues in there but the rest seems...wrong to me for whatever biased reason I have).

Overall looks good! When does Enterprise get these features? :)

We're glad you like it! This is the first of many Code Review enhancements we'll be providing, so stay tuned.

These features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).

Phabricator and Gerrit had this for ages!

The review stuff actually reminded me of http://review.ninja, which has existed for at least 1.5 years at this point.

My team and I played around with Projects for a little bit and these are things that were blockers / annoyances for us from moving away from trello. I'm posting because I know some GH people are reading these comments.

- Mobile support: Trello mobile app is great, projects web doesn't even resize for mobile.

- Slack support: Card Created notifications

- Easier “card” preview: Projects requires you to go to a new page to view a card

- Projects (1): This little "1" will always be 1. At least with PRs and Issues it means something (pending tasks, etc).

- Limited to one repo

I also found it funny that they call it "notes" as in "add note" "delete note" etc, but there is a menu item on each card that says "Copy Card URL". Maybe they renamed from "cards" to "notes" mid development? :)

I'd really like it if the Pull Requests page would denote which PRs I've already approved. That is one thing I really liked from Bitbucket, it makes it easy to skip over what I've already approved. It would become slightly more complex though, because then you'd probably want to see something for PRs you've approved but had subsequent changes on.

Great feedback point here - I've passed it along to our Engineering team.

Thank you! Can I make one more request? I'd love to be able to see merge conflicts from the diff page (also like BB does).

Knowing the conflict is just db/schema version instead of something more problematic-- that is especially handy when used in conjunction with various target branches.

i.e. I know <another-feature> branch is about to be merged before right before <my-branch> gets merged. Then, I can know what I'm going to have to fix quickly without having to go back to terminal, fetch <another-feature>, merge <my-branch>, just to find the conflicts. Yes, I have to do that with master after it's merged anyways, but I find it great to see quickly and at a glance beforehand.

Certainly - thanks for that! I've included it here.

We're aiming to monitor this board as much as possible, but if there other feature asks that come up, feel free to connect with our Support team - they're also available to take your feature asks and report them to our Engineering team.

A couple days ago I noticed that the status box on the PR page now includes a list of conflicted files. Not sure if that was in any way related to my request here, but wanted to thank you if it was. That is very helpful.

Was really hoping "forums" would mean users could add dedicated discussion boards to repositories.

If anyone from Github reads this, a) this looks great, b) add project templates please, so we don't have to recreate the same columns every time. Thanks. <3

Great idea. Thanks!

While I have your attention. A few thoughts on code reviews. It's be nice if 1) approvals somehow show up on the pull requests index page, 2) create a notification within GH, 3) send an email. Right now you have to go to the PR page itself to see approvals.

Edit: I saw an approval email notification on one PR, but not another.

Thanks!

All reviews definitely generate notifications.

We definitely want to get some way to surface reviews better across all PR's and/or projects. I've been bothered by that myself while we were building this. :)

+1 for seeing approvals visually on the pull request index page. I currently use a "Reviewed" label with my team, and unfortunately we still have to even with this feature.

Similar thing I'd like to see is repo templates. It seems for every repo I create in an organization, I spend time ticking the same boxes over and over. Protected branches for instance is a typical setting I have to duplicate for every repo.

You might be able to do this using the new graphql api :)

d) create issue templates also, i have to currently cut and paste the same markdown into every issue

e) create user-level permissions - i work on a team where everyone would use this, but currently not everyone can have access to the code base so we have to say in trello until you can allow me the ability to turn off code access to "non-engineers"

Issue templates have been a thing for some months now. https://help.github.com/articles/creating-an-issue-template-...

no shit! thanks for showing me this.

I'm actually really interested in the tech stack they used to make these new features. Specifically Projects. No latest and greatest framework or anything of that caliber. Just plain PJAX which is what everything else they have done uses. That's pretty cool to me. Looks like a pretty strong engineering culture of using stuff that works, instead of the shiniest object at the moment in time.

The inconsistent and non-sensical font and white space on the new profile pages is giving me an indescribable form of anxiety. If anybody out from the GH design team is out there, please put it back to how it was. :(.

Example: https://github.com/Miserlou

10 font sizes is too many for any one page.

I on the other hand have troubles reading it all - the contrast is way too small.

I haven't checked, but it looks like there's only three.

Just report it: https://github.com/contact

Batch review has been my #1 most desired feature for Github for many years now. This is great!

Thanks! It has been on our list for a long time as well, excited to get it shipped.

Finally, Github getting some Love! Can't wait to switch to Projects and wave Goodbye Jira. I'm a happy dev today.

Indeed, when GitLab announced Kanban I tried to migrate, but it just wasn't as great as GitHub, this is the nail in my foot that keeps me at GitHub.

What can we improve in GitLab that would have convinced you to stay?

Hey styse! You guys are doing great, don't get me wrong, every time I try you guys out, leaps and bounds. My two biggest things right now are CI docs are very very sparse and hard to figure out as they are not similar to typical CI systems, at least the ones I used (primarily Travis). And the design is very unusual, it's hard to navigate around. For example on GitHub I can click my profile and boom, all repositories right there, on gitlab, i got to go through projects, groups and all this other stuff, it's just not straight forward.

Take a look at Phabricator's project management and work board, too!

We're happy that you're happy. :) Keep the feedback coming; we're listening!

I'm liking the recent design changes, however, I don't like the new implementation of contrib. activity... information overload!

Ah, noted - so you'd like to have some customization on what you choose to show on your profile?

No, I'm saying that the "contribution activity" timeline thing is leaning towards information overload (hard to follow; there is a lot to look at). I felt that the last implementation (which focused on the high-level activities that one could click into) made sense.

I'm not a designer or anything so take my feedback with a grain of salt.

Got it - appreciate the feedback! We've been hearing some requests to provide flexibility over what's shown on the profile timeline, so your sentiments are being echoed.

Thanks again!

A minor nit: the commit graph full of green squares should not be encouraged. I don't think that kind of behavior is healthy.

Another Discourse forum. I was sceptical that the Discourse style of forum would become popular. Too complex and heavy, specially for mobile. I must admit that it's looking very good and is very usable.

If anyone from GitHub reads this, it would be great if you could use Task Lists [1] within Notes, e.g.

    Note Title.

    - [ ] Some subtask.
    - [x] Another subtask.

You could then group subtasks within a single note and tick them off as you go without having to edit the note every time. Cheers and thank you for the fantastic new features!

[1] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...

Reading, and passing that feedback along to our Engineering team. Thanks!

Batched review and pending state have both been a long time coming.

Most of the times when I do a review it's not a single comment and right now the workflow is to let the team know on Slack that I am reviewing this.

From the Gif it's not 100% clear what the pending state does but I would want something like blocking the PR until every team member that started reviewing will "release" the PR. I also see the negative side of this of course but I think the positive outweighs the negatives.

You can block merges until there's an "approved" code review in the Protected Branches setting. I don't think it has anything like "everyone who reviewed must approve" though.

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.

Can't seem to find free private repos and unlimited collaborators ?

But good to see GitHub responding - would be keen to hear from bitbucket which I personally use for private repos.

Here is a list of features we shipped in the last 12 months: https://blog.bitbucket.org/2016/09/07/bitbucket-cloud-5-mill...

The improvements to code reviews are really exciting. Having comments submit all at once instead of one at a time is a great UX change, I've definitely gotten sidetracked mid-review because somebody started responding to my initial comments when I'm neck deep. Comment threading is super useful for discussion-heavy comments like code review, and an in-UI approve/request changes is great.

That's awesome to hear - we're glad you like those changes! As you dive into it further, let us know how it works for you.

Code reviews currently do not seem to come through on the webhooks at all.

Our in-house automation suites depend on it, so this is a big do not use for us.

I really wish their APIs weren't second class citizens. It takes weeks or months for new features to show up in the API - if at all. I wish there was 1-1 parity with the API.

We definitely have plans to get full support into the API around pull request reviews.

Given how much iteration we do after an initial ship like this, especially one with as much feedback as code review, we prefer shipping the API after things have solidified and settled down after the wide release.

I sent this to support, but the "Files changed" tab in Pull Requests now has an announcement "We've made some change to reviewing code"

The "Learn more" button on that banner is a broken link…

(It's a good thing this HN post later directed me to the blog post, as now I've learned from that.)

Sorry about that! Is the link working now?

Looks like it is! (The URL that was broken now has content; the banner has since vanished for me.)

Excellent. :)

How about diffs on pull request? The biggest gripe I have with github is the inability to compare my feature branch with the branch I'm merging too. The diff you see is comparing the feature branch with the "base" branch which would be stale when working on a dev team.

I want to make sure I capture your feedback correctly, so let me know if this doesn't help: we recently released the ability to change your base branch on a PR. https://github.com/blog/2224-change-the-base-branch-of-a-pul...

Let me know if that helps!

Here's an example. It's meant to illustrate 2 developers working on a feature branch based on master and one pulls their code in before the other.

https://github.com/jparmstrong/gittest/pull/3/files

- Two feature branches were created based on master at the same time.

- Branch1: committed a change to readme and it's pulled into master via PR.

- Branch2: committed a change to readme, raised a pull request (PR#3), and the diff doesn't show the line that was added with the branch1 pull request.

In this example, the PR is telling me there's a conflict and I need to merge master with the PR branch (this is good). What it doesn't tell me is where the conflict is.

Solution, merge the base branch into the interim PR branch. The result will show you the conflict and properly represents what would happen if this PR is accepted. (Bitbucket does this)

Thanks for following up.

gist of merge master example output: https://gist.github.com/jparmstrong/07cab1a566c5c1495d7c8e07...

Got it - very helpful. Thanks for clarifying! I've copied this verbatim and sent across to our Platform team.

I think their recent change to per user pricing plays into this nicely. These features look really cool, but I can see it being costly to an organization when you have to give managers, project managers, etc. access to Github just so they can manage issues.

Gotta love a little competition.

I know, right. GitHub hasn't moved in years, until they felt Atlassian and GitLab starting to close in.

This product video for GitHub Projects features a logo that's exactly like Trello's. Cold. https://youtu.be/NoBI4_9EuUw

That's the symbol they're using for Projects everywhere. If you look at a repo, it's there.

Missed opportunity to call the platform forum the "GitHub PlatForum."

I'm not sure "missed opportunity" is the right name for that :)

Reviews are very exciting, but seem to be unable to fit the following use case:

I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).

Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.

https://github.com/blog/2137-protected-branches-improvements

I've just used the new review mode to do a bigger (still medium) sized review [0], and it was quite nice.

It's strange that I can edit any of the inline comments, but not the actual review body itself. What if I made a typo there?

[0] https://github.com/google/go-github/pull/427#pullrequestrevi...

Hmm.. So was there a workflow where I could say "I'd like for this not to be pushed until I've approved it", even if the patch is assigned to be reviewed by someone else? Of course, I could just comment with that on the issue, but it would be nicer if the issue would pop up somehow after the other reviewer has reviewed it, and it would be obvious to everyone that it's waiting for my approval.

What I really wonder right now: When reviewing my own PR on my own repo, I cannot select that the things I proposed must be resolved before the PR can be merged - why is that? Am I not allowed to keep myself from merging things I considered changeworthy or what?

GitHub is playing catch-up with GitLab. Interesting.

I just hope Github doesn't pivot in a direction that makes them no longer a safe place to archive open source code. We've had two failures already - Google Code (shut down) and Sourceforge (started putting adware on the executables of others.)

Github, please don't blow it.

Can we import a Trello project with all it's lists/cards seamlessly into a github repos `project`?

Not even close. Trello has way more features for cards. Project notes are really just a blob of text (Markdown?) and that's it. No title, description, checklists, attachments, or comments. One can imagine them coming though and with the Projects API on the roadmap you would then be able to do an import.

Definitely cool, but weren't you always able to comment inline on a PR?

The GIF shows "Start Review" button and "Finish your review" buttons (and a "Pending" flag), which makes me think this is more geared to the complaints that every comment sent an individual email instead of being batched when the reviewer was ready to send them out.

Edit: Indeed, from the github blog post - "You can also leave a review summary and delete, edit, or bundle comments before you submit them."

Maybe I can finally get my boss to switch off of Unfuddle. Although moving 10 years of history out of a couple dozen SVN repos into git would likely be lots of fun...

Now I wonder how long before some of these features such as mandatory reviews will make it into Github Enterprise?

The updated Code Review features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).

Thanks, our team was literally lamenting about lacking specific reviewers when migrating from phabricator to github enterprise last week. Looking forward to it!

Oh how I want the ability to group repos into projects on GitHub. Thought this was it. It's not.

Is this the death of Trello?

Lots of non-devs use Trello.

Trello also has lot of features this does not, but I can see GH users using Trello jumping to this, like me.

Very unlikely. We hope that Projects will be the best place for people to coordinate work on a GitHub repository, but that doesn't really limit Trello's value much. They'll continue to offer lots of value as a great way to coordinate work for many contexts outside GitHub repositories.

I'd switch instantly if:

1. There was a faster and more contextual way to edit issues on a project.

2. There was a way to set up an opinionated workflow where e.g. opening a PR against an issue moves the issue to "Review"; closing said PR moves issue to "Done" and closes it; closing an issue directly moves it to "Done" and vice versa. Without this, there's way too much interaction required for even GitHub's own preferred workflow.

3. Automatic bidirectional linking between issue/PR on the project board. (Honestly haven't had a chance to see if it does this, but will on the next PR I open.)

4. Automatically pre-fill a backlog with existing issues.

5. A project could span multiple repositories (e.g. for tracking user stories which might be addressed in an API or frontend repo, or both). We also track non-dev work on our Trello board, and a project per repo doesn't support this.

6. Filtering.

Edit... Also nice to have: ability to reference a checklist item in a link from PR to issue, check it on merge, and so on.

Hi - Codetree [1] does a lot of what you're asking for (specifically 3, 5, 6) and I love the other stuff you mention, we've been thinking hard on a couple of them. Would love to quickly chat about your workflow just to learn, not to sell, if you can spare the 15 mins. If you're interested shoot me an email at arif@codetree.com.

[1] https://codetree.com

Wonder how services like Waffle will react to this

http://blog.waffle.io/say-hello-to-wafflebot/

anyone else consider this too little too late?

I predict, one day github will host a school.

1st party link: https://github.com/blog/2256-a-whole-new-github-universe-ann...

Can we get this updated to this? defunkt didn't post this blog post before TechCrunch talked about it. I'd much rather had linked to it.

OK, we've updated the link from https://techcrunch.com/2016/09/14/github-gets-built-in-proje....

Thank you! I haven't said it lately, but the team behind this community is great. Quickly becoming my favorite forum.

Link goes right to 404 - Thats one heck of a new feature.

Heh, 404s if you aren't logged in to GitHub

Nope. I was logged in. Guessing it was something else.

I like how I got downvoted for providing information...

And still no HTTPS for github pages with custom domains...

You can use Cloudflare for that. (That's what I do on https://doma.io)

Reply on news.ycombinator.com