
Team Discussions - shayfrendt
https://github.com/blog/2471-introducing-team-discussions
======
weitzj
Another feature request:

Always show the absolute date instead of ... 14 days ago. That drives me crazy
a little bit.

I know I can hover over the date, but that takes again a mouse and 2-3
seconds.

This is especially annoying when I need to track some dates in a timesheet.

Maybe somebody has made a Chrome extension/JavaScript bookmark to circumvent
this "feature".

~~~
roryokane
You can make the absolute date appear for each timestamp on a GitHub page by
injecting this CSS onto the page, manually or with a browser extension such as
Stylus:

    
    
        relative-time::before {
            content: attr(title);
            margin-right: 0.5em;
        }
    

The result is that all relative times have their absolute time prepended, like
this:

> Nov 20, 2017, 2:11 PM EST an hour ago

~~~
nathcd
For uBlock Origin users, you can inject this style by going go the UBO
dashboard, navigating to the "My Filters" tab, and adding this line:

    
    
       github.com##relative-time::before:style(content: attr(title); margin-right: 0.5em;)
    

then hitting "Apply changes".

------
oefrha
This would be more useful if it worked for non-organizations (aka individual
users or repos) as well. As it currently stands, if I want to have a "team
discussion" with co-maintainer(s) of a personal repo, I need to create an
organization first and invite the co-maintainer(s) to a team.

~~~
dochtman
Totally agreed. I'm using Gitter now in a few places, but I think this would
be nicer to use.

I've been thinking for a long time that GitHub was really missing some way to
fill the gap that mailing lists used to be good for -- to get more of a sense
of community than what you get from issues and PRs.

------
coffeemug
I created two test discussions, and both of them (along with all replies) are
listed on a single page. You can pin discussions, but there is no discussion
search bar, and no way (as far as I can tell) to see a list of discussions
without also viewing all replies. Essentially it's a giant threaded forum,
with everything on a single page, and thread depth pinned to one.

I'm having trouble imagining how the ergonomics work out when you have more
than just a couple of largish discussions. I'm excited about this feature in
general, but I think there are some nuances they'll have to work out (unless
I'm missing something).

~~~
steveklabnik
GitHub pretty classically tends to ship the absolutely minimal feature, and
then improve it over time. That it's minimal is not shocking to me.

------
santiagobasulto
The "Project Boards" feature was replicating Trello, this is similar to
Basecamp. Good features, might be handy for small projects that don't want to
keep 10 separate tools to manage their teams.

~~~
RhodesianHunter
I sure wish they would perfect their project boards before half-assing
something new.

They're meant to replicate Trello but fall far short and see bi-annual updates
that barely address the largest pain points.

------
orta
We had just started up an internal discourse to have this exact kind of
functionality, kudos @github - great job.

------
devscreen
This is very cool! But I'm not sure how many companies it is suitable for. Any
non-dev I work with does not use github, and it would not make sense for them
to. I get that Github are releasing an MVP and this will improve but I've
found facebook workplace to be pretty awesome for this use case (non-realtime
communication / team and company announcements).

------
purescript
This seems like it could be useful, but I don't seem to be able to create a
discussion which is visible to everyone, yet only editable my members of my
team, which is my main use case (for discussing project direction and such).
"Public" seems to mean "visible to everyone in the organization".

------
Viper007Bond
We've been using something similar at Automattic/WordPress.com for about a
decade now:
[https://wordpress.com/theme/p2-breathe](https://wordpress.com/theme/p2-breathe)

We use Slack for real-time communication (it replaced IRC) but we use dozens
of these threaded blogs for making real decisions that can easily be
referenced back to in the future.

Our CEO wrote about it a little bit here:
[https://ma.tt/2009/05/how-p2-changed-
automattic/](https://ma.tt/2009/05/how-p2-changed-automattic/)

(non-Flash version of that video can be viewed here:
[https://videopress.com/v/YYNW9iSj](https://videopress.com/v/YYNW9iSj) )

We don't use email at all internally as a result.

------
lgierth
So, my colleague just started a discussion in one of our teams, it showed up
in my email inbox with a subject indistinguishable from an issue comment, and
with its own number counting (#1). That's kind of a deal breaker for me
unfortunately.

I'll give it some more time to mature before considering it :)

~~~
yuchi
Probably they implemented it just as a hidden (virtual?) project for each team
and then attached issues to it.

I mean, most of github now is rendered markdown…

------
rrdharan
This seems like a natural and useful feature, although it'll be interesting to
see how projects use these versus the "long drawn out discussions embedded in
a pull request" pattern that shows up in a lot of existing active projects
(see golang for example).

------
Navarr
Am I being silly or did github just re-invent forums?

~~~
steveklabnik
Integration is a feature. Managing big open source projects is tough, and
discussions are a huge pain point.

In Rust, we currently have a discourse instance running at
[https://internals.rust-lang.org/](https://internals.rust-lang.org/) . I just
saw the post and haven't dug into the details, but in theory, not needing to
run an entirely different service, with all of the integration work that
entails, would be really, really nice.

~~~
geofft
The similarity between Debian's mailing lists and bug reporting system (each
bug is, essentially, its own mailing list) has been helpful - you can spin off
an email thread to a bug report by Ccing submit@bugs.debian.org and including
the right metadata at the top of your reply (usually just "Package:" and
"Version:"), and you can spin off a bug report to a mailing list by just
Cc'ing it and dropping or Bcc'ing the bug itself.

If you can do things like reference a discussion from a pull request and vice
versa just like you can reference PRs from other PRs or in commits, that seems
like a huge advantage over running a phpBB somewhere else.

~~~
eeZah7Ux
Debian and Kernel developers have very functional platforms that require
little maintenance compared to GitHub & co.

Still, email is slow and kludgy. Someone should reinvent NNTP.

~~~
rhizome
Why is email slow and kludgy? I don't want to relitigate old threads, but the
only way I can see coming to that conclusion is that it's because it puts a
person back in control of their attention. What would our workdays look like
without Slack notifications?

~~~
geofft
For the Debian BTS and its mailing lists, there's no instant feedback on
whether sending a message worked, which means I have to manually poll my inbox
for a bit for errors. Every web-based platform gives me a little spinner if
needed and then an immediate confirmation that the action was accepted end-to-
end and will happen. My email client only tells me that my _local MTA_ has
accepted it, which tells me nothing about whether Debian has accepted it, let
alone whether the BTS accepted the format of my email, the mailing list thinks
I'm subscribed and will pass it on, some spam filter has decided to silently
drop my email entirely, etc.

So I get _less_ control of my attention with email. If I change a bug status
or reply to a comment in GitHub, I can send my message and be done with it.
(And I get replies in emails, not via push notifications of any sort.)

~~~
rhizome
_My email client only tells me that my local MTA has accepted it, which tells
me nothing about whether Debian has accepted it, let alone whether the BTS
accepted the format of my email,_

Is this hard to make reliable? Do other Debian contributors have these
problems?

I rarely hear of people having to babysit sending email, and by far it most
frequently comes from inside my head when I'm mucking about with my server
config, but aside from that email just works.

~~~
geofft
> _Is this hard to make reliable? Do other Debian contributors have these
> problems?_

My impression is that othrr Debian contributors do one of three things:

1\. Use the 'bts' utility, which creates an email message for you in the right
format, which adds something resembling client-side validation (with the usual
races and uncertainties of client-side validation), and last I checked still
depends on your local system being able to send mail as your actual email
account

2\. Use Debian for so long that the BTS syntax is second nature (this is
almost where I am)

3\. Not interact with the BTS, at least other than submitting bugs via the
'reportbug' utility

GitHub is miles ahead in usability by people who aren't already familiar with
the system.

------
minimaxir
My interpretation is that this is only for the Enterprise product, and not for
normal public repos. (EDIT: Apparently wrong interpretation.)

In that perspective, the feature is more akin to Jira/Confluence than
something like forums/Slack.

~~~
Navarr
It's definitely live on all of my teams, including entirely free and open orgs

------
itwy
Wow, they just rendered Basecamp obsolete.

~~~
bachmeier
Even if that were true, Basecamp costs an organization $29 per month, while
Github generally costs a lot more. I'm not sure that comparison would make
sense even if it were true.

~~~
jeremymcanally
Basecamp pricing is actually $99/month now, which puts it out of reach for
every use case I'd have for it at this point. :( I haven't seen an affordable
competitor yet for orgs that aren't technically-inclined.

------
Dowwie
Now where's the "migrate issue to a discussion" feature?

~~~
roryokane
GitHub doesn't even have a “migrate issue to pull request” feature. I think
the solution GitHub would recommend would be to link to a discussion in the
issue comments, and to optionally lock the issue as well.

~~~
jamie_ca
They used to, at least via the API. Before we switched to JIRA for issue
tracking at $dayjob, `hub pull-request -i <issuenum>` was a part of my daily
workflow.

------
maxxxxx
Is this similar to Slack?

~~~
lojack
looks less realtime, closer to a forum

------
flurdy
So more like Yammer than Gitter.

Ie very asynchronous long life discussion, and searchable. Not real-time chat.

------
contingencies
Does anyone else just use issues or markdown files in the repo for this?

------
jonas21
Seems like this is just the "Issues" tab for organizations?

~~~
bpicolo
There are all sorts of things you want to last indefinitely rather than as
issues. Newsletters, etc. The goal for issues should be 0 open. That's a much
different use case

~~~
marcosdumay
> The goal for issues should be 0 open.

Why?

There are even tags there for helping you make sure the relevant issues are
being resolved. You don't need to treat all of them equally.

------
xrd
Another shot across the bow to Atlassian.

------
samuel1604
It feels like Google Wave has reborn!

~~~
dbbk
In what way? This doesn't replicate any of Google Wave's features.

