7 ms·

The New GitHub Issues

156 points by hswolff 12y ago

siong1987 12y ago
just one quick feedback - it will be awesome if the whole bar is clickable instead of just the title of the issue.
- mdo 12y 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.
transientbug 12y 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.
- mdo 12y 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! <3
  - transientbug 12y 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 12y 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!
- chrismorgan 12y ago
  I always viewed the issues list including pull requests as a feature.
  - mdo 12y 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 12y 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 12y 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 12y 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 12y ago
  To exclude any labels you can use -label:css. Works with most other filters too.
chrismorgan 12y 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.
- mdo 12y 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 12y 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 :)
- kdaigle 12y ago
  Definitely a great idea. Keep an eye on webhooks...
- kdaigle 12y ago
  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
erichurkman 12y 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.
- mdo 12y 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.
  - erichurkman 12y 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.
    - scrollaway 12y ago
      A similar argument can be made the other way: The OP can be edited to include further tasklists if needs be.
      - erichurkman 12y ago
        True, but then you lose comment notifications, and edits can't be made simultaneously to the same post by multiple users.
        scrollaway 12y ago
        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 12y ago
Exposing the search bar is a very nice addition. However, I'd still like a quick filter that gives me "involves:<me>".
- justsee 12y ago
  That exists: https://help.github.com/articles/searching-issues#involves https://help.github.com/articles/searching-issues#involves
hrjet 12y 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.
- mdo 12y 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.
  - hrjet 12y 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 12y 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).
    - scrollaway 12y ago
      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.
matthewarkin 12y ago
I can filter by not having a label attached! Ex. "-label:"90 - Complete"" will show all issues not labeled complete!
- holman 12y ago
  Related: `no:label` will show you everything that's not labeled in your repository, too.
larsberg 12y 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 https://github.com/servo/servo/pulls )
wise_young_man 12y 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.
- scrollaway 12y ago
  FWIW the issues are still there if they are re-enabled. You could try asking the repo owners.
yeukhon 12y 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.
rogerbinns 12y 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.
- scrollaway 12y 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.
  - watwut 12y 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.
qwerta 12y ago
I would like the issues to become part of Git repository. Perhaps some folder structure in separate branch.
- travisb 12y ago
  Sounds like you just want to use a distributed bug tracker. There are several to choose from: http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTracking2013-04-20 http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...
minikomi 12y 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..

156 points by hswolff 12y ago

siong1987 12y ago

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

mdo 12y 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.

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

mdo 12y 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! <3
- transientbug 12y 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 12y 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!

chrismorgan 12y ago
I always viewed the issues list including pull requests as a feature.
- mdo 12y 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 12y 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 12y 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 12y 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 12y ago
To exclude any labels you can use -label:css. Works with most other filters too.

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

mdo 12y 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 12y 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 :)

kdaigle 12y ago
Definitely a great idea. Keep an eye on webhooks...
kdaigle 12y ago
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

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

mdo 12y 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.
- erichurkman 12y 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.
  - scrollaway 12y ago
    A similar argument can be made the other way: The OP can be edited to include further tasklists if needs be.
    - erichurkman 12y ago
      True, but then you lose comment notifications, and edits can't be made simultaneously to the same post by multiple users.
      - scrollaway 12y ago
        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 12y ago

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

justsee 12y ago
That exists: https://help.github.com/articles/searching-issues#involves https://help.github.com/articles/searching-issues#involves

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

mdo 12y 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.
- hrjet 12y 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 12y 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).
  - scrollaway 12y ago
    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.

matthewarkin 12y ago

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

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

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

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

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

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

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

scrollaway 12y 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.
- watwut 12y 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.

qwerta 12y ago

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

travisb 12y ago
Sounds like you just want to use a distributed bug tracker. There are several to choose from: http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTracking2013-04-20 http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...

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