Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Discussions Beta

github.com

Post reply on HN
Print view View original

131–140 of 141 posts

Re: GitHub Discussions Beta

#131

Post by leerob »

alexellisuk wrote: post #92

This links to Zeit, which seems like a kind of advert for their product? How do we actually find out about GitHub Discussions and opting-into it? Or did GitHub only enrol one company into the beta?

It doesn't appear that GitHub has announced anything about Discussions on their site yet. My guess is that a few select large repositories (e.g. zeit/next.js) are trying out the beta to provide feedback. We'll probably get some official communication from GitHub shortly, with the ability to sign up for the beta.

Re: GitHub Discussions Beta

#132

Post by seer »

wincent wrote: post #116

New features are great, but I wish they'd make more of an investment in improving their core code review functionality. The lack of an "interdiff" view (between revisions of a PR) and the lack of a proper way to mark PRs as dependent on one another really limit the utility compared to other code review platforms (thinking specifically of Gerrit and Phabricator/Differential here).

Github has a really great url api - you can usually do git related compares right there in the url - github.com/some/repo/compare/HEAD...comitsha is actually a thing.

And while not particularly ergonomic you can have PR against other PR since forever.

Github is built by devs for devs and has tons of hidden gems scattered in there. Do read their shortcuts help, blog and other dev sources and you might find tools for a lot of the task you can think of.

Re: GitHub Discussions Beta

#133

Post by IceSentry »

frou_dh wrote: post #124
kvark wrote: post #18

GitHub is slowly eating the surrounding cities. Github pages replaced our hosted sites. Projects replaced Trello/Waffle and friends. Actions replaced Travis/CircleCI. Sponsors is about to hit Patreon, and now Discussions aims for a piece of StackOverflow pie... I think they are doing great in terms of performance and UI, it's hard to resist the convenience of having everything linked together in a coherent way. But t…

> [GitHub Project boards] replaced Trello/Waffle and friends. I've actually wondered whether that feature (the Kanban style boards) will end up going away, as it seem vastly underused by the overall community in comparison to Issues/Milestones/Wikis. Go to a random substantial repo and click on the Projects tab. It's almost certain that there'll be nothing there.

I agree that it doesn't get much use, but I still think it's a good feature to have. I personally prefer having a project board integrated with everything else instead of using an external service.

Re: GitHub Discussions Beta

#134

Post by Game_Ender »

hrpnk wrote: post #123

A problem with such products offered by GitHub is the fact that they're connected to a single repo. This is maybe suitable for monorepo situations or simple open-source libraries. However, teams work differently and need to manage backlogs across many repositories. The context is usually a team, project, etc. This requires pulling in multiple issues across repos into one backlog along with abilities to manage this ba…

Phabricator works great at the scale you are talking about. With a single monotonic issue number for your company (like Apple's Radar). You have to ditch GitHub totally though, and use Phabricator for code review or the wiki too to get the benefit. Avoid it's repo hosting and CI component (harbormaster). The thing you will miss most is the web based file editing.

My advise would be to deploy: Phabricator (issues, code review, wiki), Buildkite (CI - with your own AWS runners), gitolite (repo hosting).

Re: GitHub Discussions Beta

#135

Post by Game_Ender »

wincent wrote: post #116

New features are great, but I wish they'd make more of an investment in improving their core code review functionality. The lack of an "interdiff" view (between revisions of a PR) and the lack of a proper way to mark PRs as dependent on one another really limit the utility compared to other code review platforms (thinking specifically of Gerrit and Phabricator/Differential here).

According to the CEO's twitter account [0] they are release better support for dependent PRs this year, track progress of that feature here [1].

The crucial problem with code review on GitHub is that it's 100% dependent on Git to store the history of a PR. This too closely couples what a developer does locally on their machine to the code review process. This in turn means that force pushing drops the history of their "Checks" system, which annotate the PR with CI job an lint/test results. It also means junk commits on PRs make the whole review process more difficult. The app Reviewable [2] works with GitHub and fixes some of these issues if you want to give it a try.

0 - https://twitter.com/natfriedman/status/1170804894241972224

1 - https://github.com/isaacs/github/issues/959

2 - https://reviewable.io

Re: GitHub Discussions Beta

#136

Post by Game_Ender »

seer wrote: post #132
wincent wrote: post #116

New features are great, but I wish they'd make more of an investment in improving their core code review functionality. The lack of an "interdiff" view (between revisions of a PR) and the lack of a proper way to mark PRs as dependent on one another really limit the utility compared to other code review platforms (thinking specifically of Gerrit and Phabricator/Differential here).

Github has a really great url api - you can usually do git related compares right there in the url - github.com/some/repo/compare/HEAD...comitsha is actually a thing. And while not particularly ergonomic you can have PR against other PR since forever. Github is built by devs for devs and has tons of hidden gems scattered in there. Do read their shortcuts help, blog and other dev sources and you might find tools for a…

That feature breaks down in the presence of merges. But when those are not present it works OK, you see lines like this:

> force-pushed the aojea:affinity branch from 8eab3f7 to ee626e7 yesterday [0]

Where the "force pushed" links to a pretty decent UI [1], but it will include a bunch of non-import information if the person rebased and force pushed, which is a common reason for force pushing.

You can see that in this [2] long lived Kubernetes PR that was rebased, the resulting "helpful" link shows me 2094 changed files [3]. In a tool like Gerrit or Phabricator this is automatically handled and it would basically ignore this operation unless the rebase changed the code being reviewed.

0 - https://github.com/kubernetes/kubernetes/pull/88409

1 - https://github.com/kubernetes/kubernetes/compare/8eab3f73163...

2 - https://github.com/kubernetes/kubernetes/pull/85000

3 - https://github.com/kubernetes/kubernetes/compare/375873cb532...

Re: GitHub Discussions Beta

#137

Post by SahAssar »

quantummkv wrote: post #96
silverwind wrote: post #91

Aren't all issues discussions in essence? I think they'd have been better of just renaming issues and adding categories like "Issue", "Discussion" etc. Some projects already do this via labels.

Not really. Issues are problems/bugs/etc that directly affect the product and are related to code. Discussions are for thing that are not related to code, like a user asking for some guidance regarding the code. > Some projects already do this via labels. That was an illogical hack do to limitations. Good on Github for identifying and fixing that.

So the only functional difference is that they are shown on different tabs?

Re: GitHub Discussions Beta

#138

Post by viraptor »

treve wrote: post #106
viraptor wrote: post #89

Earlier quoted context omitted.

That's not what the close button does and it typically requires a few confirmations from other users, so you can't close things randomly yourself. Almost all close votes are reasonable - have a look at the "close vote" moderation queue. It may seem beginner hostile sometimes, but in practice it's mostly: you can't have a personal approach to everyone when looking through hundreds of messages.

I'm at 60k reputation so I have a decent idea of how it works. My point is that you probably should have a personal approach before voting 'close'. If you don't, there's no real harm in leaving bad questions open until there is someone else in the community willing to help out. I find myself looking at closed questions wanting to help but unable to too many times.

I don't disagree. I just don't think this can be enforced in any way. Community defines itself. We've got 75042 people who can cast close votes. Requiring multiple votes helps, but you can't make that many people behave the same way with the same values.

Re: GitHub Discussions Beta

#139

Post by icebraining »

frou_dh wrote: post #124
kvark wrote: post #18

GitHub is slowly eating the surrounding cities. Github pages replaced our hosted sites. Projects replaced Trello/Waffle and friends. Actions replaced Travis/CircleCI. Sponsors is about to hit Patreon, and now Discussions aims for a piece of StackOverflow pie... I think they are doing great in terms of performance and UI, it's hard to resist the convenience of having everything linked together in a coherent way. But t…

> [GitHub Project boards] replaced Trello/Waffle and friends. I've actually wondered whether that feature (the Kanban style boards) will end up going away, as it seem vastly underused by the overall community in comparison to Issues/Milestones/Wikis. Go to a random substantial repo and click on the Projects tab. It's almost certain that there'll be nothing there.

I'm guessing those are way more used for private projects (inside companies) than public ones.

Re: GitHub Discussions Beta

#140

Post by icebraining »

chrisseaton wrote: post #117
clarry wrote: post #109

Earlier quoted context omitted.

> Maybe we need a comment DAG instead? HN comments are a DAG. DAGs are branchy, which is the problem. It seems like you want to merge or rebase the two comments and then reply with a new node pointing to the last of them.

> HN comments are a DAG. Come on don’t be pedantic you know what I mean - I mean a DAG that is not also a tree - so using the merging property of a DAG. If HN were a DAG then I could make this reply to your comment and someone else’s on another part of the discussion at the same time. > merge or rebase These are source control terms - I’m not sure how they apply here.

> These are source control terms - I’m not sure how they apply here.

Git is a DAG too.

Post reply on HN