The New GitHub Issues

https://github.com/blog/1866-the-new-github-issues

by hswolff • 12 years ago

156 47 12 years ago

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.

mdo6• 12 years ago

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!

transientbug2• 12 years ago

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

bluetidepro• 12 years ago

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!

chrismorgan2• 12 years ago

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

mdo6• 12 years ago

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.

masklinn• 12 years ago

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.

bhousel• 12 years ago

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.

mjschultz• 12 years ago

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• 12 years ago

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

chrismorgan2• 12 years ago

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.

mdo6• 12 years ago

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.

dangoor• 12 years ago

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

kdaigle2• 12 years ago

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

kdaigle2• 12 years ago

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/

erichurkman3• 12 years ago

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.

mdo6• 12 years ago

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.

erichurkman3• 12 years ago

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.

Narretz• 12 years ago

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

justsee• 12 years ago

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

hrjet2• 12 years ago

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.

mdo6• 12 years ago

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.

hrjet2• 12 years ago

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.

aktau• 12 years ago

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

matthewarkin• 12 years ago

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

holman• 12 years ago

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

siong1987• 12 years ago

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

mdo6• 12 years ago

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.

larsberg• 12 years ago

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 )

wise_young_man• 12 years ago

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.

scrollaway6• 12 years ago

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

yeukhon• 12 years ago

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.

rogerbinns2• 12 years ago

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.

scrollaway6• 12 years ago

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.

watwut2• 12 years ago

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.

rogerbinns2• 12 years ago

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.

phloxicon• 12 years ago

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.

qwerta• 12 years ago

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

travisb• 12 years ago

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

minikomi• 12 years ago

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

The New GitHub Issues

Related Stories