Live data from Hacker News

GitHub Discussions Beta

github.com

111–120 of 141 posts

Re: GitHub Discussions Beta

#111
post #76
post #34

Earlier quoted context omitted.

Why? It seems to me the real thing open source projects ought to have is control over their data / autonomy - having some service control your forums and publish the code they use to run them doesn't seem like much of an advantage, if you can't apply patches to their system. For instance, while it helps Debian that their GitLab instance salsa.debian.org is open source, how does it help a non-Debian-affiliated project…

Having your OSS discussions on Slack is pretty terrible, it’s a closed source silo where things can’t be found via Google or even with the included search if you are above the limit. Every time I see an open source project asking people to “Join our Slack” it makes me sad. Besides, I’m in too many Slacks already. I really don’t need one Slack account for each project I want to follow.

> it’s a closed source silo where things can’t be found via Google or even with the included search if you are above the limit.

How is that different from, say, IRC? How is it relevant that Slack is closed-source?

If you want to run an open-source project on Slack, run a logger that dumps things to a publicly Googleable archive - same as you would if you were running the project on IRC or on a mailing list or whatever.

If Slack says that running a logger is a violation of their terms, then that's a reason to avoid Slack in particular - but not with closed-source services in general. It's a problem with services run by someone else, open-source or not. And in fact, Freenode (which runs an open-source ircd) has a policy that if you log, you must say so clearly in the topic and you must respond to requests to remove portions of logs.

To be clear, I think that if a project says, out of idealism we will only use FLOSS forums, and we don't care about meaningful control over it, we just want to encourage other people to run FLOSS to promote the movement, that's totally reasonable. But if your concern about non-FLOSS platforms is practical and not philosophical, I'd argue what you actually care about is control over the platform.

> Besides, I’m in too many Slacks already.

I have this problem too, but it's not really about whether Slack is open-source or not, it's about the specific software. (Also, from experience, being in over a hundred channels in irssi is actually less manageable....)

Re: GitHub Discussions Beta

#112
post #86
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…

Replaced is incorrect, they're simply competing. Trello and CircleCI are alive and kicking.

CircleCI might be alive and well, but Travis-CI is on the way out, and I'd not be surprised to see CircleCI go out in a few years.

Re: GitHub Discussions Beta

#113
I'm not sure if this is necessary. Github, from the beginning, is a platform where we host our source code. I've never needed a discussion board because there are other sites that are precisely serving discussion boards, like StackOverflow. The idea of having everything on the same platform sounds easy but that is also taking out the opportunity of being a simple and elegant tool. Microsoft is changing Github since they acquired.

That makes me question ( because they are Microsoft), What happens when they add everything inside Github and then they don't like it? Will they have an opportunity of closing Github? Switching it to something inside their office tool? May be office suite for developers? Combine Visual Studio with Github and discussion boards and todo lists and CI tools... ???

I'm the kind of developer/product maker who likes to use a diversity of products. That feeds my creativity and makes me think differently.. I don't want to lose that one.

Anyways...

I wanna ask something different, What do you think if StackOverFlow adds git hosting? Will it work?

Re: GitHub Discussions Beta

#115
post #109

Earlier quoted context omitted.

Here's a concrete example where I think it goes wrong. You say something, and two people respond. There's one thing to say in response to both people - maybe they both misunderstood part of your point. Which comment do you respond to? On places like HN people seem to feel the need to respond to both branches, which causes exponential growth if it continues, compared to if you could respond to the two comments as one.…

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

Hacker news comments are a restricted DAG where a node can't have multiple parents. Obviously they're referring to that property.

The branches could come back together again.

Re: GitHub Discussions Beta

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

Re: GitHub Discussions Beta

#117
post #109

Earlier quoted context omitted.

Here's a concrete example where I think it goes wrong. You say something, and two people respond. There's one thing to say in response to both people - maybe they both misunderstood part of your point. Which comment do you respond to? On places like HN people seem to feel the need to respond to both branches, which causes exponential growth if it continues, compared to if you could respond to the two comments as one.…

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

Re: GitHub Discussions Beta

#118
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…

Well that's microsoft 101, what did you expect?

Re: GitHub Discussions Beta

#119

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

My god, would LOVE PR interdependence. Esp if I could leave a review like "approved after #123 is merged"

Re: GitHub Discussions Beta

#120

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

You can compare any two commits. Maybe I’m misunderstanding, but isn’t that sufficient for you to see the diff of PR revisions?

If the issue is reviewing the code, stale reviews for code that was pushed over will be marked as stale.

Post reply on HN