GitHub Discussions Beta | Hacker News Reader

GitHub Discussions Beta

github.com

249 pointsatymic138 comments

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 this will probably backfire in the future :/

Why would it backfire? This centralized approach is the entire model for competitor Gitlab which has grown without issue so far.

I believe GP is predicting it will backfire on the users who buy into the ecosystem, not Github itself.

I understood the point to be that to do all these things well is very difficult for a single product / company. I worked at a startup where our solution was to replace five other solutions. Only customers with the simplest use cases found that it worked. The complexity from the breadth makes achieving the requisite depth for a good experience difficult.

Because Microsoft effectively building a monopoly on OSS. I'm happy now, because the product is amazing but it's always sain to have everything controlled by one company.

I don't want to make the same comment repeatedly, but anyone saying this aims at SO is fundamentally misunderstanding why SO is successful and what it offers.

SO is literally anti-discussion, the whole point is it is about questions and answers, not discussion, because finding answers to questions on forums was a nightmare. No one wants to read through a thread of context to maybe find an answer.

That isn't to say discussion isn't useful or valuable, it absolutely is, it is just a completely different thing. This is competing with Discourse, not SO.

It still competes with SO because now you'd post the question about a certain framework or library on its repo's discussions. Also, isn't it kind of explicitly doing that because discussions can elect an "accepted" answer?

Yeah, but way more people look for answers rather than ask them (not to mention the pain of having to answer the same question repeatedly if they can't find the answer).

Accepting an answer is an attempt, but without the moderation, editing, voting, duplicate closing and so on from SO, the quality and ease of finding answers won't be there.

I'm sure plenty of people remember trying to find answers through forums, and it was a nightmare. The thread might not actually have an answer in it, and even if you get pointed to an answer, it'll often need context from the rest of the thread, it might be out of date, or completely wrong.

To put it simply: there is a reason why people use SO almost exclusively for Q&A, and there is a reason people still use forums and stuff as well. Discussion and Q&A have different goals and conflating or combining them leads to pain for users.

even though many projects actively try to dissuade "user" questions and direct you to SO. Now they'll maybe send you to the relevant discussion. This is closer to the "source" for answers specifically linked to one repo or project. For more general questions, we'll see if GH broadens what discussions can be used for; if there will be a place for more general topic discussions

It’ll be very interesting to see how Google ranks the search results. I don’t know about others, but I almost never directly search SO, and almost always end up there through Google. If GitHub Discussions has the answer and Google directs me there, I will definitely not visit SO as often anymore.

I've found the questions that SO surfaces when writing my questions to be pretty good.

Stackoverflow's search algorithm sucks compared to Google. I always use google and add the "site:stackoverflow.com" operator to find answers on SO.

To be fair pretty much everybody’s sucks compared to Google. I think your approach is almost universally sensible.

It looks exactly like SO to me. There is a question, it is voted on, and there are answers, with one selected as the correct answer. There is no reading through the entire thread or anything like what you are suggesting.

It also competes with Reddit.

I am a long time user of SE (questions and answers alike) and I go to reddit for questions which are more vague (because I do not know where to go) or the ones which invite discussions.

I can't wait for stack overflow to fall out of favor. There's few places as beginner-hostile as SO. If you get enough points, you get the close button, which effectively is telling newcomers to RTFM in nicer words.

Yeah, and it's full of low quality drive-by responses by people using it to build their personal brand. Not quite on the same level as say Quora, SO seems to have better checks in place to keep things from degenerating that much. It's definitely present though, just less overt.

Anecdata: I have a question where I was calling super() incorrectly, and another where my reproduction was flawed, not showing what I thought it did. No closures or hostility. Maybe I've been lucky, maybe the advice for asking good questions works.

In any case the act of composing a question according to the guide has answered many more questions than I've actually posted -- some due to the rubber-ducking, others via the "check out these questions" feature.

(This is all orthogonal to the recent issues wrt moderators and community managers)

Stack Overflow has only become more popular since I used it.

I used to answer people's questions. These days I'll go to a section like Node.js and frankly anyone who asked a good, focused question has been answered and you're left sifting through the low-tier questions of people posting an unformatted 1000-line code snippet with "it doesn't work".

Seems to be working pretty well.

Quite the contrary experience, it's specially hostile to knowledgeable people. My last 3-4 questions were all closed because I wrote targeting experts and the mods had trouble understanding what I was asking.

Do you have an example?

Not without sacrificing my privacy :(

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.

SO is one of the few places on the internet that give me a positive experience pretty much every time I go there.

Type in my programming question, go to the page, scroll down and see a wide variety of idiomatic, well-researched and thoroughly critiqued solutions, very readable, ready to copy, and with the concepts spelled out to study up on.

I was wondering whether Github issues (and now discussions) are exportable?

*Just found the answer: https://developer.github.com/v3/issues/

I find it maddening that git hasn't added a standard mechanism for metadata.

Commit comments are metadata. Tags are metadata. Why isn't there a general-purpose metadata plumbing so we can attach issues, merge and commit discussions, and wikis, in a portable way?

No, being able to export from one centralized repository and import into another isn't good enough.

You can attach as much metadata as you want using git-note.

The Pagure git forge keeps all project metadata (issues, PRs, etc.) on git, so you have it all if your Pagure instance ever goes down & can easily move it to another instance:

https://pagure.io/pagure

I dunno about that. The only thing I use is GitHub Actions. Projects pales in comparison to Asana, and Pages is a nightmare compared to Netlify or NOW.

At the same time, there are still many things that could be improved in the traditional/core Git workflow, and it seems like those are not getting as much attention.

https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-...

> Sponsors is about to hit Patreon

At least for Patreon, they have a large enough user base, this won't hit them particularly hard.

I’d imagine open source is just a small slice of the pie compared to the youtube/twitch/gaming audiences. And I imagine any project earning thousands on Patreon isn’t going to attempt to migrate all of that just to keep it in github.

It will probably only affect Patreon’s share of FOSS-projects starting today (and thus doesn't already have a Patreon).

Of course if enough people start using GitHub Sponsors, end-users may make it a expectation/demand to be able to sponsor their favourite projects there if they are going to bother (much like users today won’t bother to sign up for a Patreon-competitor).

And then it might start having a noticeable effect.

That said, anecdotally speaking, today only one of my Patreon pledges are for software projects, and most are for youtubers.

If that holds up for other people too, I suspect Patreon will be fine.

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.

Travis was already on its way down before Github actions

>it's hard to resist the convenience of having everything linked together in a coherent way.

I don't like having my revenue generating activities linked to a social network for programmers. It seems like a terrible mix. I am not social at all. I know programming has now become a "social" thing as it is in the mainstream, but I prefer the days of it being an obscure world where you had to join some kind of mailing list.

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

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

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

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"

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.

While it's a bit tucked away, when you are viewing the changes for a PR, there is a dropdown in the top left for “Changes from <all commits>”. You can select any range there to view changes from that range of commits.

When you've left a review, you also generally get a “View Changes” button in the conversation that takes you to the changes since you last viewed, if new changes are pushed. The issue with this particular link is it tends to be ephemeral.

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.

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

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

One feature that is missing with this, and with every discussion forum since usenet , is a tree-view of a thread.

On my Thunderbird I still follow some usenet forums and it is so much clearer and quicker with a tree view to see who has replied at what point in the thread. Poring through reams of quoted replies just to find where in the thread the answer comes doesn't cut it.

Do you think this kind of deep-threading, or tree-nesting, encourages a forked conversation, with everyone in the discussion trying to respond to individual comments in an ever-growing tree, rather than responding to the current conversation as a whole? I find mailing list threads that are trees very hard to follow. It's probably a conscious decision.

I've found trees encourage forked conversations in a good way. While I don't find them hard to follow, I do find revisiting them to be a bit difficult. While it can seem difficult to follow the overarching topic given a set of trees, it's near impossible to have any in-depth discussions about more than one thing in flat threads.

I have given these models lots of thought and have come to the conclusion that the success/failure of hierarchical conversations is determined solely by the presentation. Common mailing lists and email UIs leave the most to be desired, while HN, reddit, sbnation community sites, etc show a path forward. But nobody has implemented the view properly enough to let you see the forest and the trees at the same time (yet).

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? Responding to an arbitrary number of comments? Maybe comments that aren't even siblings?

> Maybe we need a comment DAG instead?

Internet messages (Usenet, email) already work that way. If you want to reply to multiple messages, this is easily possible.

Most users are not familiar with it because the widely implemented threading algorithm prunes the graph into a tree for display purposes. https://ddg.gg/?q=jwz+email+threading

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

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

What do you think about Zulip's format?

Most conversations get forked anyway IME. An easily navigable tree view supports that much better imo.

Also the problem with Twitter although the boundaries of distinct conversations there are different. Trying to follow any conversation there is like a game.

Tree-view doesn't exist once there's a global reply box. A `comment.parent` pointer only makes sense on a website like Reddit where the user is forced to reply to someone.

Else you have a situation like most forums (phpbb, vbulletin, xenforo, etc) where tree-view is useless and unused because only a fraction of the posts have any sort of parent relationship. Besides, the idea of tree-view never really caught on in those fuller-fledged forums I listed as you could be quoting any number of people and have more than a 1:1 argument like you're forced to on Reddit/HN.

In other words, I don't think a forum lacks a tree-view when it's also lacking the entire reply paradigm.

> every discussion forum since Usenet

4chan + 4chanx would like to have a word!

> One feature that is missing with this, and with every discussion forum since usenet , is a tree-view of a thread.

Uhm... have you ever heard of a little-known site called "Hackernews"?

Or the even more niche 'Reddit'.

I wasn't particularly clear, apologies. I was really referring to instances where navigating the tree view was a core part of the interface.

This means being able to expand and collapse the tree easily, as well as identify quickly nodes that have replies.

On a typical Usenet reader, new replies are normally highlighted, and read nodes/subthreads can be quickly collapsed, often by default.

Neither of those are possible with HN, Reddit or typical NodeBB sites where every post is displayed whether read or not.

Gitlab or Slack style threading would be better option for discussions instead of tree-view.

Superb. Many open source projects still bounce you to Google Groups for discussion, which is archaic at this point. Even requires Google login just to read threads.

Also it's often unclear what the policy is on raising questions in the issues tracker (smaller projects are usually fine with it, bigger projects get overwhelmed and don't want it). This will make it a much nicer separation for everyone and keep the issues tracker minimal.

I can read Google groups just fine in incognito mode.

https://groups.google.com/forum/m/#!forum/golang-nuts

It's a matter of what the settings are on the group (the group admins get to decide visibility settings).

One thing nice about Google Groups is that you can largely use it to its fullest extent from email.

Yup, use through email is huge, especially when combined with not having to create an account — just join the mailing list. I do have some personal experience with this: when we added the backwards compatibility to email to our team discussion tool (Aether Pro), the usage shot through the roof. To email users, it just looks and acts like a much better, 21st century version of Google Groups.

(We also offer it to open source communities for free as well: https://aether.app/email)

> To email users, it just looks and acts like a much better

Hmm, I'm not completely convinced it would (but I haven't used it, so take this opinion with a grain of salt). Responding to rich text emails is somewhat cumbersome in most mail apps, because there's a tendency for formatting to get all mixed up and it makes simple things like quoting nontrivial.

Yeah, I know how that goes. Our formatting is pretty neutral — we just offer a good readable text size, make everyone use the same font and colours so no one is writing in hot pink 16pt Comic Sans, allow Markdown, have a mobile design and dark mode in the emails. I've personally spent the midnight hours to make sure this all works nicely with existing email.

It's an ongoing battle but not an intractable one. It's not perfect, but we've gotten it to pretty good already. It definitely survives being quoted and otherwise chomped on by Gmail, Mail.app, Outlook, iOS and Android mail clients, which are our five main test cases.

idk, i really enjoy the 10+ second load time of Groups

Proprietary project management tools - slack, github issues, PRs, discussions, etc are terrible places to host OSS communications. Use open source tools.

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 that happens to use that service?

So there are two separate things you could be interested in. One is, am I running my own service? Most people don't want to be 24/7 volunteer sysadmins, it turns out. (A few do, like the people who run salsa.debian.org: more power to them. A few open source projects can pay sysadmins, which also solves the problem.)

The other question is, can I get my project's data out of someone else's service if I want to migrate? It turns out that you can do that for many closed-source forums.

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

> Even requires Google login just to read threads.

Fun fact: if your session is "expired" but the cookie says you have an account, it forces you to log in, even if the group is public. Workaround: incognito mode.

Sorely needed. Tons of projects use issues for discussions/questions..or redirect to stackoverflow.

I wonder what will be the reduction in stackoverflow due to this ?

One request - have a global "discussions search" . Repos are interconnected to each other. I don't want to have to restrict my topic search to one repository's discussions

StackOverflow actively discourages "discussion"—it is for questions and answers. If anything, I'd say it overlaps more with issues than this.

I don't know what stackoverflow discourages, but tons of projects explicitly mention "ask questions on stackoverflow with this hashtag"

Having a place to do this right next to the source code would be welcome (as long as there is global search as well)

E.g. https://kubernetes.io/docs/tasks/debug-application-cluster/t...

Stack Overflow

Someone else from the community may have already asked a similar question or may be able to help with your problem. The Kubernetes team will also monitor posts tagged Kubernetes. If there aren’t any existing questions that help, please ask a new one!

In terms of displaying content, asking questions is a very different thing to discussion. If you've ever had to trawl through forum threads trying to find answers, it is a nightmare. StackOverflow is much more heavily moderated and curated to keep the answers from being buried.

In general, you aren't going to be able to discuss something on SO, and people aren't going to find answers in discussion boards because they don't make it easy to find those answers.

I know what you mean, but given great search, this is not going to be massive difference. But the ability to link to source code lines/issues/pull-requests as part of the discussion is going to be good.

Here's the thing - I would bet there's an overwhelming majority of users, who "discuss" and ask on GitHub issues anyway. And half the job of repo owners is to close such issues.

So it's not like the natural behaviour of users is to go to stackoverflow for questions/discussions anyway. This just channels existing behaviour

They send you to SO with questions which have specific answers. If you want to have an actual discussion that involves multiple people, SO is not the place and will close the question very quickly.

Sorely needed and really not that expensive of a feature to build. Really nice bang for the buck. This should make Github much more pleasant once it spreads across most projects.

Definitely a welcome addition, but it's funny that after all this time the solution was just to copy-paste the Issues tab and rename it. In fact in our public repos we have a "Discussion" label for such issues and it has worked pretty well.

¯\_(ツ)_/¯

Finding such a "simple" and effective solution for a long standing problem is the software development dream.

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 backlog and calculate metrics.

I've seen some teams manage an 'issues' repository solely with tickets that are later linked to the individual repos' issues and PRs. It's quite a mess and GH does not seem to offer issue statistics and comprehensive query capabilities to manage issues.

Has anyone worked with an issue management system (not JIRA) that would be working across 100+ delivery teams and have decent integration with GH/GHE to show PR progress, issue status, releases, etc.? Any experience with FB's https://phacility.com/phabricator/ for example?

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

Congrats on shipping!

I like how quickly GitHub is shipping new features now, compared to earlier: the mobile app, Actions, Sponsors, security scanning, etc.

That said, I was a little disappointed that Discussions is essentially identical to Issues :(.

While I can't pinpoint any specific issues I've had with Issues for discussions, I was hoping GitHub found, and found solutions for, pain points that users didn't know they had with Issues.

It's a little different. You can mark which comment answers a question, and comments can be voted. We will probably find some other things we want Discussions to do differently, too, as we iterate.

Thanks Nat! I would also recommend writing a blog post announcing Discussions and its features as soon as you get the chance.

Reading this HN thread, I got the impression GitHub actually did just copy/paste Issues into a new tab, as a commenter mentioned, a belief that was backed up by a cursory look at Next.js's Discussions.

Now I see that's not fully the case.

Phew. I've pretty much given up subscribing to issues on well-known projects because they so often get swamped by useless posts from people desperate to take their opinions for a walk (I pity the maintainers).

Hopefully this will reduce the issue spam problem.

I have no idea if my suggestion four years ago helped but am glad they finally implemented it :) https://github.com/dear-github/dear-github/issues/44

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?

That's like saying a link to react on github is an advert for Facebook

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.

Interesting, I thought this was going to have something to do with their acquisition of Spectrum, but it appears to be an entirely separate in-house feature. I wonder what's going to happen to Spectrum longer term then.

https://spectrum.chat/spectrum/general/spectrum-is-joining-g...

I had the same thought. Especially since the Next.js maintainers said that Discussions would eventually replace their Spectrum community.

Maybe GitHub acquired Spectrum with the intention of slowly migrating its userbase over.

This looks like the perfect mechanism to help us disambiguate code-related items from discussion items. We could say something like "Close this issue and link it to a new discussion"... Will give this a hard look when it's available on our org account.

I've been waiting for something similar to this for a long time. There's a lot of questions & topical discussion that don't fit well into issue.

I wasn't able to find GitHub page covering this feature, so the link to to Next.js's repo discussions.

Interesting. Will this be rolling out to other repositories at some point to beta-test?

I haven't seen any official announcements, and this was the only repo I found that had it enabled. Hopefully it rolls out to a wider audience soon!

Yep! We're going to try it out in a few interested communities, and if people like it, we'll make it available GitHub-wide. It's early, though, and we want a chance to learn what works and iterate on a smaller scale before introducing it to everyone.

Quibbling over the details is a given, but people are going to like it. It fulfils such a clear need.

Is there any way to apply for the beta? I'm maitaining few communities that could really use this feature!

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?

Is there a real desire to separate these from issues? We use issues to have discussions and it’s never a situation in have been unhappy with.

Issues are about bugs in the project. Discussion are about bugs in the person. It's true that it is not always evident which domain a bug exists and so some spill over is natural.

Oh love it! I’m always unsure if it’s ok to ask a question via issues.

Thanks! Hopefully helps you find answers, too :)

I'd assume that this has a similar scope to team discussions[0] released a few years ago. At the moment most larger projects have communities elsewhere, and smaller projects use issues for this king of discussion.

Compared to other community forums it's distinguishing feature will be referencing commits and issues. I'd be interested to see how many projects actually use this feature.

[0]: https://github.blog/2017-11-20-introducing-team-discussions/

Interesting, having worked with github orgs for since this was released, I never actually knew this existed. It actually look pretty cool, sad that it didn't get much traction.

Will there be an option for internal discussion? For example ticking off the "internal" checkbox makes the thread visible to team members and collaborators only.

You can already do this with team discussions (which has been around for a few years).

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?

So, how do I join discussions beta?

AFAIK there's no way to join yet, and there's not even any official posts about it (that I can find).

We’re testing it out with a ZEIT for now, working to improve things as we go.

Can we please have organizational account-wide discussions?

Tangential question, is github a proof that not every complex app has to be an SPA and it can worked really well or is this legacy thing from their part?

Curious to know if they feel they could iterate faster new features for the UI if it were an SPA.

A lot of apps that started with Rails take that approach, including Github, Airbnb, Basecamp (which technically started Rails), and a few others.

Some companies start API first or mobile app first, which makes SPAs much more likely.

It is only natural progression here. Heck, I am surprised it took this long. Considering the fact that in many Github projects, "Issues" were being used for discussions, questions, often tangents.

Github is becoming more and more diverse. the style of Github has always been a professional discussion about issues or features. But now it may be changing, Maybe because users are becoming more and more willing to use it as a forum to discuss something it's maybe not that useful on it. Now Github has opened up an area to do this, which may be a good thing while maintaining professionalism and making the community is more like a community.

One problem with GitHub's version of these features is how they're tied to repos or organizations. My team works on many projects across repos and GitHub orgs and we have to use ZenHub instead of GitHub Projects because of these barriers.

This seems like it'll be great for getting Q&A and random thoughts out of issues, but it won't replace broader boards and lists.

Slack?

Concerns include record retention policy and terms of use governing redistribution of the content

Hmm. So this will be like a classical forum basically?

can't wait for slack being on target for GitHub

(and not just a team integration please... :D)

They just need to create an integrated gitter clone now, or maybe buy it from gitlab. Also this step pretty much kills discourse, doesn't it?

GitHub bought Spectrum (spectrum.chat) in 2018:

https://spectrum.chat/spectrum/general/spectrum-is-joining-g...

But I would caution against integrating too many tools into GitHub. As a user, I like that GitHub errors on the side of saying no. You don't want to end up with a bloated product.

As long as they retain the option to disable certain features on a repo, I am wholly in favor of consolidating the development stack into GitHub. Easier to mandate 2FA and other security procedures when your team doesn't have to juggle several sites.

Friendly aside: the expression is "err(s) on the side of..."

Zeit's was the most active spectrum community I was part of, interesting they're the lead tester community for this new GH feature. Spectrum fell between a number of posts, it was never really "chatlike" so it looks they've gone completely in the forum direction with discussions.

Reply on news.ycombinator.com