> Edit: Nevermind. The document they cite[0] clears it up.

That didn't exactly clear it up for me. Would you mind saying how that clears it up? Does it really mean 1-249 after all?

I still don't grok the dos and don'ts of NSLs and canaries, but that document establishes the origin of the range 0–249, which is expressly permitted. See also: https://canarywatch.org/faq.html

I suspect they would not be using the 0–249 band if they were not gagged by a previous order. My uninformed interpretation is that they have received an NSL or FISA order, but not necessarily in 2015. So the 2015 number might be zero after all.

Maybe someone more informed could confirm or debunk this interpretation.

It means in bands of 1000 starting with 0-999.

Or bands of 250 if you classify things a different way. It offers both options.

Yes.

colinodell posted that before the blog announcement when we only knew about issue_template.md. It was to point out that you can do this with pull requests as well, not that it was case insensitive.

> This is the first of many improvements to Issues and Pull Requests that we're working on based on feedback from the community

So there is more to come

Geez. I would hope so. Too bad it took them the better part of half a decade to listen to users. I've already moved a number of my personal projects to Gitlab, Bitbucket or a self-hosted Gogs installation.

I've still got reasons to stick with Github for some projects, but it's not the new hotness it used to be.

$10 says the next new feature is voting on issues.

If the next feature is voting on issues then that would be great. They'd be implement Ling the features people are asking for.

GitHub had issue voting years ago and got rid of it because people hated it.

Yes. It works on issues too.

Yes. When you subscribe to an issue you show that you are at least interested enough to receive notifications about it.

Eh, I don't like getting spammed with notifications when I'm subscribed to a popular issue. Maybe that will be less of a problem with fewer people posting +1 comments, but still. I wish I could just get a notification when the issue is closed.

Sure, but what if I don't care about being notified of ongoing discussion for an issue, and instead just want to be notified when it's been closed, or maybe a pull-request has been submitted?

Do you get many issues that don't use your template because people go to /issues and click the new issue button? When I create an issue with a project, I typically don't a link in readme.md.

You could combine it with the new feature and put a warning message into the default box saying to click one of the links in the README in order to get an issue through.

That is just... Why? That's such a UX failure I'm not entirely convinced you wreent being sarcastic.

But why...

Admittedly we use it on private repos so we haven't seen an issue with it, but there isn't anything from stopping you putting the link in other places

It's not that the link isn't in the right place. It's that regular old users like me are familiar with the Issues -> New Issue workflow, and will continue to go right to that whenever we want to create an issue since it's a guaranteed way to create an issue.

This isn't true of GitHub as a whole, and I'm not sure it is true of any part of GitHub. Their team page shows everybody on staff in the order they were hired. Scroll to the bottom and you will see that there is no shortage of white people being hired. https://github.com/about/team

Is that up to date? They used to introduce each employee on their blog but they hadn't done one for months last time I checked.

It's up to date. It has people who started last week.