Under the "All the small things" section of the post:

> "You'll get a notification if an issue is assigned to you."

> "No more mixing: the "issues" tab will only show you issues, and the pull requests tab will still only show pull requests..."

> "If you use Task Lists, we'll show the overall progress on that issue or pull request on the listing page: "

Yes! These are three features that I have been waiting on for awhile now. Especially now that I don't have to open a ton of tabs to see task lists for each issue. That's so awesome the task lists are now in the list UI.

Great work, GitHub!

I always viewed the issues list including pull requests as a feature.

You can totally get to this by removing the `is:issue` or `is:pr` from the search field. That'll show everything, regardless of type.

IME, it's very common for people to open an issue and immediately or soon after open a separate PR for the issue, so you end up with lots of duplicates (or more if the original PR is abandoned and new ones are created, or there are competing PRs for an issue). Having both PR and issues in the issues list just made it unwieldy.

I confess that I have occasionally gotten this mixed up, i.e. see a pull request in the issues list, confused it for an issue, and "fixed" it by implementing the same thing that the pull request did.

This is nice. There are two things however that would make GitHub issues awesome:

1. Starring / Voting an issue. The count of stars/votes should be visible and we should have the ability to sort by the number of stars / votes.

2. Labels with values. Simple integers types would do to begin with. For example, priority:1, priority:2, etc. And then being able to sort by the value.

We've long discussed voting. It probably definitely won't ever happen in the near future.

You can set create `priority:1`, `priority:2`, etc labels right now and sort by those values. Not quite the same as what you want, but it's a pretty close solution until we figure out the next features to add to Issues.

A bit sad, as a member of a big project on github, I'm sure that "starring" could be a handy way to know what people are interested in. (And avoid a lot of "me too"-comments, from devs and other users alike).

I think Google Code does this one right: "Subscribe" is a star and you get notified -- star counts are public. I hope github adopts that model.

Do you mean internal discussions? What is the main reason to not support voting?

Priorities are a necessity for large projects. One could use a full-fledged issue tracker, but having an integrated one in GitHub would be miles better.

I'm still confused by the inability to do prioritisation. Why does Github so stubbornly not have a way of doing that including sorting on it? I am aware you can create arbitrary labels, but that doesn't help with sorting.

We long ago gave up on Github issues because of this, and use Trello instead where priority is simple drag and drop. The other problem is that you can't easily copy/move/link issues between repositories. This becomes necessary when you have different repos (eg a server one, an android one and a web one) and something is reported against the "wrong" repo. Not the reporters fault, and very tedious to correct.

This is all one area where Google Code does things so much better (yes you can prioritise and sort). Each project can have any number of repositories and they all share the same wiki and issue tracker. That is a lot easier to deal with. Of course refusing to take money, and apparently losing interest means it can't be used.

The problem is you always have to cut features somewhere to remain clean.

Look at bugzilla: So many fields most people don't need. Who needs to separate "Resolved" and "Closed" for example? Who cares about the OP's platform when you're building a web app? And why is "importance" different than "priority"? Why is there a keywords field, a tags field AND a whiteboard field? Wtf.

But all these are actually useful to some people out there. The problem is the end result is a mess. I find github issues to be good enough for 99% of non-massive/non-corporate projects out there. People can just go check out your project and add 3-4 bugs/suggestions as easily as they would comment on a blog post.

Personally what I miss is being able to flag a bug as a dupe of another. But again, do most projects need that is the question.

Prioritisation is something I see in every other tracker. If items are dispatched/fixed/closed from the tracker faster than they come in then it doesn't matter, but that is rarely the case. The moment there is more available issues than can be worked on right now, prioritisation needs to be done. The are many criteria that could be used, but "priority" is a pretty established one. The problem with github issues is there seems to be no viable way to get that.

I agree about having lots of different fields. I once worked somewhere where after a series of acquisitions 11 different bug tracking systems were collapsed into one! Having arbitrary labels mitigates most of those. IIRC Google Code also lets add as many different states as you want so that works too, letting projects be as simple or complicated as suits them.

This os why Django uses Trac. Github issues can't handle that much traffic, triage as a simple Trac installation with a couple of pkugins.

Less important thing that can be done in two hours may have higher priority then more important thing that requires twelve man-moths of development. Or higher then one we have no idea how to do so far.

Priority is more about scheduling and importance ignores planning/managerial issues.

We used "Resolved" and "Closed" for two different things in work too. I was missing those distinctions on afterwards.

You're telling me things I already know. The problem is that, realistically, there are no differences in most project. And if there are differences, odds are high you either have grown too big for github issues or you have a bureaucratical mess of metawork in your tracker.

Remember, always remember: A tracker is supposed to help you develop your software faster and better. Meta-work should never get in the way.

It was zero additional work. Importance was filled by analyst and priority when planning. It was very neatly managed project, one of the best I worked on. If it is kept neat, those things help a lot.

Github labeling way of prioritizing and what not is actually harder to keep then fixed fields. You can live with that, but it requires more effort and attention to be useful.

Anyway, the problems the parent complained about are not in priority/importance category. The inability to do prioritization more practical then labels or milestones is a big thing. It is standing in a way, because you have to spend too much time in issues list and essentially re-prioritize in head again every time you are looking for something to do.

I love the way you can star issues on Google Code. Sorting by stars shows the feature most people want. Github could really use this.

Is there a way to search by the status flags? It's now harder to see them since they're no longer in the same column, and I use the "has passed tests" filter frequently to check which PRs might need shepherding on Servo (https://github.com/servo/servo/pulls )

I would like the issues to become part of Git repository. Perhaps some folder structure in separate branch.

Sounds like you just want to use a distributed bug tracker. There are several to choose from: http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...

I mostly like this, especially the way in which things like label/title changes are finally displayed.

You know what I would really like to see next? A bit of adaptive design. Something that will let me use a narrow viewport without needing to scroll back and forth all the time.

Eh, adaptive/responsive features are not that much of a payoff for us honestly. It helps with a few edge cases of screen splitting, but there are far bigger changes we can make than spending time on that. I wouldn't rule it out, but it's not at the top of our list right now.

Two feature requests:

1. hiding issues

2. CC people / stop notification

For example as more and more teams are using Github, and although the spirit of open source is collobration, sometimes security bugs are probably better handled if they are hidden until resolved.

There are two ways to do this now:

* email

* bugzilla / bug bounty site

Wouldn't it be awesome if I could just let people report security bugs on Github except they are hidden as opposed to managing and tracking tickets from multiple places?

I know now you can CC people using @ but what about muting notification? As a bugzilla user, I can stop being notified if I remove myself from the CC list.

This is nice and everything, but the one thing that I don't like so far is that getting to the list of labels isn't just a sidebar away anymore but instead a whole tab change. I do see that you can filter by label through the filter textbox, but that isn't quiet the same for someone like me who uses the colors more than the name of the label.

Overall, looks nice though. Curious to hear what power uses think of it.

Hey there! Try clicking on the labels within the issues list—they are linked up to quickly adjust your search without typing. Not quite the same, but hopefully it helps!

<3

Oooh, that definitely helps a fair bit. I think the label dropdown in the panel head is nice and what I'll end up using the most often. Still have to find all the little changes hidden around this :D

One thing I noticed recently that really bit me was I created a few issues on a public repo which decided to disable issues and so I lost them forever.

FWIW the issues are still there if they are re-enabled. You could try asking the repo owners.

I can filter by not having a label attached! Ex. "-label:"90 - Complete"" will show all issues not labeled complete!

Related: `no:label` will show you everything that's not labeled in your repository, too.

just one quick feedback - it will be awesome if the whole bar is clickable instead of just the title of the issue.

Up until a few weeks ago, we had the whole issue clickable. It'd toggle the select checkbox for bulk actions across multiple issues/pulls. However, we opted to skip that as missing a click on say a milestone name, user avatar, or label would then toggle that issue's selection. It'd be even worse if the accidental clicks sent you to a specific issue as you'd get inadvertent loads and have to go back.

Bottom line? Too frustrating for common use, so we skipped it.

I'd love support for an issues.markdown - which appears at the top of the issues list or above the form for creating a new issue. I have a moderately popular web app which it want to keep client side only but which gets constant requests to add saving / server side..

This is great! One thing that I was not able to find: is the activity tracking around labels exposed in the API? We (the Brackets team) actually wrote a tool to collect data about when a label was added or removed and it would be a welcome change to not have to support that :)

And we just shipped that via http://git.io/1hV9Ug and you can get the events through the API at https://developer.github.com/v3/issues/events/

:D

Definitely a great idea. Keep an eye on webhooks...

I seem to get a 500 error page whenever I search for something along the lines of "NOT label:css". I was hoping to be able to find issues that are not labeled as something.

Other than that this seems like a great improvement!

To exclude any labels you can use -label:css. Works with most other filters too.

All great updates, but it's missing one key thing for us: the checklist tracking only includes check items from the first post on an issue thread. Any checklists in subsequent issue comments are not counted.

I think we do that because what happens if random contributors jump in and start adding even more random task lists? We could probably do some checks to prevent that, but this is at least a safe and practical way to do it as a first-pass.

Yeah, I can definitely see that for public projects. That said, the subsequent comments could just be edited to remove the extra checklist if it were an issue.

A similar argument can be made the other way: The OP can be edited to include further tasklists if needs be.

True, but then you lose comment notifications, and edits can't be made simultaneously to the same post by multiple users.

You can get comment notifications by hitting the Subscribe button. The latter seems like a good problem to have, and one which you would normally not hit if you're still using Github issues.

Exposing the search bar is a very nice addition. However, I'd still like a quick filter that gives me "involves:<me>".

That exists: https://help.github.com/articles/searching-issues#involves