Since it's URL is to the login page when I middle-click it to open in a new tab it actually opens up the login page in a new tab.

Firefox 3.0.something under Linux.

Adding the hash to the URL breaks the back/forward button.

Example:

Start: https://github.com/defunkt/github-issues/issues

Click on "Welcome to Issues"

Now hit the back button or "CMD + left or right arrows"

It would be nice to bind a gist to an Issue. Mainly for code samples :D

It might be nice to let the submitter add some labels to an issue.

Maybe let the admins pick certain labels for public use.

That way I could have put a label on this called Suggestion or Enhancement.

Might be a good start to adding Issue types ;)

Maybe add a checkbox like on support.github.com

• default labels or people-tags for each contributor

• email the person when an issue gets tagged with their name (or send GitHub message)

• your dashboard could display the most important issues with your label/tag

• another sort by option for "owner" -- might be tricky if you can tag more than one person -- really I just want to filter by stuff with my label, which I could do from labels as-is

Any other ideas for ways having special people-tags could be useful? Or is this too much?

Since we are allowed to self-vote our own issues, it really only makes sense for the issue to be auto-voted for by the creator.

I'm fairly sure the creator is going to be in favor of whatever issue they filed. ;)

I would like to add people who can work with wiki & issues (or just wiki) in my private repository but don't get access to the code.

Since the e-mail paradigm is in use here, why not provide an IMAP interface?
That way, people could use their mail program to manage issues.

Alternatively, and perhaps more universally, you could send an e-mail for every new issue / comment, which can then be collected by users in their own mail as desired. Having an interface similar to the debbugs tracking system (where you can close, reassign, prioritize several bugs in just one e-mail) would be fantastic.

Currently, the showstopper for me is the lack of an export facility. Especially since bugs are referenced in commit messages (neat!), we need to be able to get a serialized version of the issues database out of github. Exporting to e-mail would certainly address this.

If you are going for the Gmail-style navigation, then holding down j or k should be able to move you through multiple issues. The current behaviour requires you to keep pressing j or k to navigate the list.

Just as with Twitter @replies, it'd be neat to log in to Github and have a list on the homepage of all the issues tagged with one's name.

Great bug tracker!

Being a big git fan, I often work offline. It would be wonderful to access my project's issues as a git repository in some user-friendly format, so that I could browse them and add notes when I didn't have a network.

Or just tell jnunemaker to stop posting issues ;)

This is a great addition to the web UI, but significantly increases lock-in to the GitHub service. The best addon features you have implemented are those which directly build on the raw git repository, itself (like Pages). Google Code similarly does this for Wiki content (which I'd also love to see on GitHub). Including a rich web interface to issue tracking which is also stored directly in the git repository would be a huge boon.

See https://github.com/blinks/mtgcauldron/issues

After creating one issue and adding a label, I get Unread (-1) on the sidebar. I assume this should be Unread (0), or (-1) has some meaning I don't quite understand. Sweet to have integrated issue tracking, though!

Create a Eclipse Mylyn Plugin (see [[https://www.eclipse.org/mylyn/]]). This need some API.

For example, I have the Issues URL:

https://github.com/tjl/sage_int_testing/issues/closed/#issue/1

which has the link to my commit:

https://github.com/tjl/sage/_int/_testing/commit/5f38e60

Note the additional / in front of each of the underscores in the project name.

The issues feature looks great, but we already have an established system. We would like to direct users to that instead. Is there a way that same link could be set to our external tracker?

let members rank and allow anyone to see
1) his ranking
2) some-members ranking
3) collective ranking

This project has no source, and when I go to the main page I get "nothing to see here" and no tabs. Since there are issues, I would expect to see the issues tab at least.

Simplicity is great, but convenience can be very sweet too...
Right now if there are duplicate issues (e.g. more than one person listed a bug) one can put a mark on the comments (with the markup) as

 This is a duplicate of #Number

which would linkt to the Issue #Number
It would be great to be able to mark an issue dupplicate of another, and this info to be listed on both issues:
Duplicates of this issue: .....
and
This issue is duplicate of: ....

Since the GitHub flavored markdown seems to be quite different from the markup used anywhere else (at least to me), it would be great to be able to optionally choose a preview of the comment before submission. Right now the only way is to edit an already submitted issue/comment, which is not as convenient and can be a bit stressful when one's using markup for the first few times...

An example:

Alos opened issue 4 on Alos/xyzradio https://github.com//Alos/xyzradio/issues/4/find

Just like the title says... syntax highlighting in code snippets would be a nice feature.

Right now this issue tracker only features open / closed issues. I think there should be other states like started, accepted, wontfix or something like that.

Maybe you also let the users define their issue states and integrate states into labels. Right now you have to use labels to do something like that, but it doesn't integrate that well into the UI. Issues labelled wontfix will still be open issues if you don't close them.

Using many labels on a issue will shift the title to the right of the issue overview resulting in truncation. Maybe it would be best to give up the fixed height issue fields.

The "search issues" should check commenter's name as well, not just the comments' text.

Closing an issue with comits is done by writing something like either of the following two in the commit message:

 Closes # 1
 Closes gh-1

(there's no space between # and 1, but it get's renderend wrong here if I write it like that) This however does not seem to extend to more than one issue. For example, trying either of the following will only close the issue 1, and leave 2 open.

 Closes gh-1, gh-2
 Closes gh-1, Closes gh-2

There is no "Delete" option for issues (i.e. mistakenly or accidentally created).

In the comment body, if a # is followed by a number, it is translated into a link in the github flavored markdown. that can cause problems, e.g. <a href="/defunkt/github-issues/issues/#issue/1" class="internal">#1

Should include some escape character that ommits this automatic translation.

If an issue requires more than one commit to fix, how can you link to the issue in the commit message without closing the issue?

Commit messages on a fork repository should able to reference issues on the main repository.

Use case:

1. someone find a bug and create an issue.

2. she forks the project

3. she pushes the fix to her fork with a mention to the issue in the commit message.

4. GitHub link the commit to the issue on the main project issue tracker.

5. GitHub add a comment to the issue linking to the fix on the forked repository.

If I write a comment in Russian then comment don’t post with a message “Comment must not be empty”.

Wouldn't it be great to "paste" a whole file out of your repository with a single line of "GitHub Flavored Markdown" into an issue?

Examples:

• Code: lib/my_class.rb resulting in a code tag containing the whole content of the file lib/my_class.rb into the issue.
• Code: lib/my_class.rb[10,30] resulting in a code tag containing only lines 10 to 30 of the file lib/my_class.rb into the issue.
• Code: lib/my_class.rb@#sha resulting in a code tag containing the whole content of the file lib/my_class.rb from commit identified by #sha into the issue.
• Code: mybranch:lib/my_class.rb resulting in a code tag containing the whole content of the file lib/my_class.rb from branch mybranch into the issue.

Any combinations (and maybe files from other projects) should be possible, too.

For perfomance purposes the code from the file should be saved right into the issue, so it don't has to be read from the repository every time a user reads the issue.

Issue Affects-version/fix-version fields.

• Where version is a tag or a branch in the repository.

Thanks for a great tool! Henrik Johansson

Allow me to vote -1 because sometimes I just feel like being a party pooper.

To replicate the current workflow we're using in another issue tracker, I would like to be able to assign labels to an issue via commit message. We typically work with the following flow.

New -> Accepted -> Resolved -> Closed

New tickets would be just that, new, and wouldn't require a label. When a developer accepts an issue, they can simply add the issue, but when they commit the fix, they could commit it with "gl-resolved #4" and it would add the label 'resolved' to that issue with the same benefits as closing an issue (link to the commit, etc etc).

Then when our manager goes through and reviews tickets labeled 'resolved', he can go ahead and close them once the code and functionality has been reviewed.

It would be nice to be able to comment as a response to a specific comment in an issue. On the other hand hierarchical structures can be a PITA. Worth having? Vote it up if you think so.

When I issue a search query for a word that should only be in one ticket I always get the entire list of tickets. Searching does seem to work on the github-issues issue tracker though. Is the indexing queued?

When making a commit, I included ticket numbers for both my Github issue and the ticket number for another issue tracking system (as we tidy up there and migrate to github). The commit closed and correctly linked to my Github commit with the Github issue reference, but a link was created for the other ticket number that just ends up as a dead link.

I would have expected the functionality to ignore that number as it has no associated issue in the repository.

Example:

"Resolves #2948 (other) and closes #2 (Github). Fixes bla bla bla"

#2948 gets linked to a non existent issue while #2 is correctly linked to the commit.

For example, I'd like to be able to enter 'label:aeden label:accepted' in the search box and find issues that have the label aeden and the label accepted. In general I'd rather see all filtering go through the search box.

See title

(In the original description here, I thought this was more of a feature request. But then it turned out that this should work, it just didn't work for me)

Pressing the '?'-key does not open the help lightbox.

However, at least the 'j', 'k', and 'c' works (the only ones I've tested).

• OS: Linux, ubuntu 8.04.1
• Browser: Firefox 3.08

The atom feed links to https://github.com//julien51/babylon/issues/2/find, but should be https://github.com/julien51/babylon/issues#issue/2.

I'm using a norwegian keyboard and need to press 'shift 7' to get '/'. Pressing 'shift +' to get '?' works fine.

It would be great if the comments had an info field if they'd been edited. Sometimes the conversation does not make much sense if a comment's been changed (e.g. after people replied), and this would at list give a sign that the original text was different.

The dialog box for deleting labels doesn't work, the label is deleted even when "cancel" is pressed.

If I am viewing one issue and I change the issue number in the URL, I have to reload the page to see any effects (just pressing enter leaves me viewing the issue I was at before). FF 3.0.8.

Hello,

It seems that when I call : curl -F 'login=#{GITHUB_LOGIN}' -F 'token=#{}' https://github.com/api/v2/yaml/issues/list/#{GITHUB_LOGIN}/#{GITHUP_PROJECT}/open I get a "That page doesn't exist!" error if the repos name has a dot in it. The same curl call with dot-less project name and it works.

I've also posted a ticket here, don't know which is the best place ...

Best, Thomas.

It would be nice to be able to create an issue by e-mail (e.g. : automatic app error notifications could then be forwarded directly to the issue tracker)