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