
The New GitHub Issues - hswolff
https://github.com/blog/1866-the-new-github-issues
======
bluetidepro
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!

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

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

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

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

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

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

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

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

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

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

------
larsberg
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](https://github.com/servo/servo/pulls)
)

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

~~~
travisb
Sounds like you just want to use a distributed bug tracker. There are several
to choose from:
[http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...](http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTracking2013-04-20)

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

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

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

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

~~~
mdo
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

~~~
transientbug
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

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

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

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

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

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

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

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

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

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

:D

------
mjschultz
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!

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

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

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

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

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

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

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

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

~~~
justsee
That exists: [https://help.github.com/articles/searching-
issues#involves](https://help.github.com/articles/searching-issues#involves)

