Team Discussions | Hacker News Reader

Team Discussions

github.com

236 pointsshayfrendt53 comments

Open articleView on HN

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

Agreed, this should really be a toggle switch in the user profile. The information about the date doesn't change, just the displaying of it.

It should be a simple thing, and it'll cater to more people's workflows.

Stack Overflow does it well: recent posts are shown with relative times (e.g. 7 minutes ago), but beyond a certain point, the date is absolute. E.g. arbitrary question https://stackoverflow.com/questions/47019433/expo-io-always-...

I like Discourse showing larger intervals:

Comment A

Comment B

2 years later

Comment C

Arbitrary example thread: https://internals.rust-lang.org/t/parameterized-modules/2883...

GitHub does the same thing: https://imgur.com/aXw1bHR

Relative dates are the worst. So many times I'll see screenshots (useless!), or an old browser tab which stops updating, or I need to see which of two items from last month is the most recent (perhaps only minutes separating them, but both items show up as "one month ago"). So many apps (and webapps) fail to offer absolute dates as an option. Looking at you, gitlab.

Looking at you, this very thread on HN as of 2017/11/20 6:19PM PST

romwell 2 hours ago

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

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

As an occasional workaround, if you leave your mouse cursor over the "14 days ago" text for a few seconds, then the absolute date will appear as mouseover text.

Not easy to cut-n-paste, but at least it can be shown as-is without needing to inject CSS or similar. :)

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.

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.

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

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.

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.

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.

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

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

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

We've been using something similar at Automattic/WordPress.com for about a decade now: 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/

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

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

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

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…

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

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

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

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.

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.

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?

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

> there's no instant feedback on whether sending a message worked

> So I get less control of my attention with email

Exactly what I wanted to reply. There are corner cases where an asynchronous medium forces you to multitask.

On top of that, email was is not meant for threaded, group discussion. NNTP was: you can organize groups, access and search past discussions before you joined them, and run a decentralized/distributed service without fiddling with domains, DNS, DKIM... in comparison, email is kludgy.

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.

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

Exactly this. I'm currently planning to move a small community off a SimpleMachines self hosted forum where I upload files every day. I was looking at GitLab as an option, because I can automate daily file delivery by cron pushing to the private repository. I was trying to decide if the Issues could somehow be used in place of a forum. After deciding they couldn't, my next thought was Discourse.

However, if GitLab had this integrated discussion board it looks like it could be the right solution.

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.

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

Wow, they just rendered Basecamp obsolete.

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.

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.

$99

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

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.

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.

Is this similar to Slack?

looks less realtime, closer to a forum

So more like Yammer than Gitter.

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

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

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

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

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

Another shot across the bow to Atlassian.

It feels like Google Wave has reborn!

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

Reply on news.ycombinator.com