
GitHub Discussions Beta - atymic
https://github.com/zeit/next.js/discussions
======
kvark
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 :/

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

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

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

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

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

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

~~~
Game_Ender
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](https://github.com/kubernetes/kubernetes/pull/88409)

1 -
[https://github.com/kubernetes/kubernetes/compare/8eab3f73163...](https://github.com/kubernetes/kubernetes/compare/8eab3f7316381a5bc91104881d9f77ee0430e56c..ee626e77bfd2d69dd378eade3d86a297f3bbab45)

2 -
[https://github.com/kubernetes/kubernetes/pull/85000](https://github.com/kubernetes/kubernetes/pull/85000)

3 -
[https://github.com/kubernetes/kubernetes/compare/375873cb532...](https://github.com/kubernetes/kubernetes/compare/375873cb532942035b9e6479f044a9184cf0e5a6..ee8f410ca145b028d352be2d9498fcbcf95cb517)

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

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

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

~~~
chrisseaton
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?

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

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

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

Git is a DAG too.

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

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

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

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

~~~
geofft
> _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....)

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

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

~~~
sandGorgon
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...](https://kubernetes.io/docs/tasks/debug-application-
cluster/troubleshooting/#help-my-question-isn-t-covered-i-need-help-now)

 _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!_

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

~~~
sandGorgon
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

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

~~~
natfriedman
¯\\_(ツ)_/¯

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

------
hrpnk
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/](https://phacility.com/phabricator/) for
example?

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

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

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

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

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

------
vjeux
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](https://github.com/dear-github/dear-github/issues/44)

------
alexellisuk
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?

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

------
ss3000
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...](https://spectrum.chat/spectrum/general/spectrum-is-joining-
github~1d3eb8ee-4c99-46c0-8daf-ca35a96be6ce)

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

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

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

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

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

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

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

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

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

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

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

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

~~~
simpsoka
Thanks! Hopefully helps you find answers, too :)

------
qqii
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/](https://github.blog/2017-11-20-introducing-team-discussions/)

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

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

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

------
erdinc
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?

------
tamalsaha001
So, how do I join discussions beta?

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

~~~
riobard
Can we please have organizational account-wide discussions?

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

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

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

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

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

~~~
someuser54541
Slack?

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

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

------
Despacito2019
can't wait for slack being on target for GitHub

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

------
animalnewbie
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?

~~~
veeralpatel979
GitHub bought Spectrum (spectrum.chat) in 2018:

[https://spectrum.chat/spectrum/general/spectrum-is-
joining-g...](https://spectrum.chat/spectrum/general/spectrum-is-joining-
github~1d3eb8ee-4c99-46c0-8daf-ca35a96be6ce)

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.

~~~
thisBrian
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..."

