isaacs / github

Just a place to track issues and feature requests that I have for github

IMPORTANT NOTE: GITHUB NOW HAS AN OFFICIAL FEEDBACK REPOSITORY. OPEN A DISCUSSION THERE TO ASK QUESTIONS OR DISCUSS BUGS. THIS REPO IS DEPRECATED.

Issues for GitHub

What this repository is about

This is not the actual repository for the GitHub website.

I'm not affiliated with GitHub in any way, except that I use it all day long, and almost all my code is hosted there.

UPDATE: as of April 2020, with the acquisition of npm, Inc. by GitHub, I am a GitHub employee. I remain focused on the npm/cli project, and any opinions expressed here belong to the person expressing them at the time they were expressed, and should not be taken as official GitHub policy in any way. I still use GitHub all day long, and almost all my code is still hosted there.

Issues and feature requests posted to GitHub are not stored in any publicly available location, so I find that I quickly lose track of the things that I've sent them.

For GitHubbers

If you are a GitHubber, and you would like to respond and close issues on this repository, please let me (or one of the other collaborators) know, and we'll add you as a collaborator. Alternatively, you could use some secret GitHub internal APIs to get access, if you have such things. If you want to know what people are asking for or ask for them to provide details about use cases. Then head over to the issues list.

If you have an issue or feature request for GitHub

1. Search for existing issues
2. If you did not find any existing issue for your topic, post a new issue
3. Additionally, please email [email protected] because this repo is strictly for our own (unofficial) tracking purposes. Make sure to send GitHub the issue URL at the end of the message so that they can more easily find updates and further comments here.
4. If GitHub replies, (and they usually do, quickly) and if it is not a confidential matter like a security disclosure, add their reply to the issue so that other users know what their official response was.

Upvoting existing issues

Upvote existing issues with thumbs up 👍. Please do not add +1 comments.

If you merely want to +1 an issue (isaacs/github#9), please also send an email to [email protected] to register your interest. Be sure to include a link to the tracking issue that was filed.

See more in CONTRIBUTING.md

Issue closing policy

Issues will only be closed once GitHub implements / fixes them, or explicitly says WONTFIX, which almost never happens nowadays. Issues may take a long time (forever) to be fixed, so make sure that you are ready to keep them around on your /issues list for a long time.

See also

• Dear GitHub

Statement of Intent

This repository is created in a spirit of positive intent and community good will. I have more love in my heart for GitHub than anyone probably ought to for any website. They've changed the face of open source, and enabled amazing things to happen. I've personally benefited quite a bit from those amazing things, and my life is much better as a direct result.

I'm very thankful to GitHub, and the great work they do. When I shake my fists in frustration, it's only because they are so good that I spend countless hours being productive on their website, and even minor problems seem to jump out.

Trolling, disparaging remarks about GitHub, or even just unproductive kvetching, will not be tolerated. Those comments will be deleted and the users blocked.

We're here to help each other, and the company that does so much for us.

<3

--isaacs

github's Issues

Gist comments and mentions don't trigger notifications

this used to work.

to reproduce:

• make a gist
• have someone leave a command or @ mention you
• you won't receive any emails

Stickiness of label/milestone issue filter is frequently surprising/weird

If you filter the issues list by a label or milestone, then that becomes "sticky", so that any subsequent visit to /issues will apply the same filter.

Then, to un-set that, you can click (x) Clear label/milestone filter.

That in itself is kind of unusual, but easy enough to get used to, I guess.

However, when you clear it, it doesn't update the url, and simply visiting a url with the filter in the query string will cause it to become sticky again. So, this happens:

1. Visit issues page.
2. Apply a filter
3. Clear the filter
4. Click an issue
5. Click "back button"
6. Filters are re-applied. Expect: filters remain cleared.

Bonus: Applying filters should not be sticky in the first place. Just change the url. If I go to a new url (ie, one without the filter query string params) then show me a different thing.

Allow users to filter the organization news feed by repository

Link to stars points to "following"

Steps to reproduce:

1. Open someone else's profile (try mine: https://github.com/stepantubanov)
2. Take a look at the "starred" link (it is the same as "following")

Try the same with your own profile. This time link will be /stars.

Easy way to generate list of issues open or closed

I think it would be great if we could export a text file of issues based on current view options (current milestone, or all if no milestone).

I think it could be kept simple. This would make it easier to copy those issues over to other sites/software we use for discussions (for example: basecamp and chat).

Gmail thinks Pull Request comments are signatures and hides them

Every email I get from Github pull requests hides the content of the email and only shows the quoted code.

I'm guessing this is because Github formats the email in a way that makes the actual text look like a signature.

It shouldn't be difficult to format the email in a way that doesn't break in gmail.

when adding PR comments, default code blocks to the language of the file getting the comment

Somebody sends you a pull request and you have some feedback.

If the file your comment is in is .js then default ``` blocks to format as javascript.

If the file your comment is in is .json default ``` blocks to json.

Etc...

If replacing 's behavior with js (for example) then how about putting a magic icon on the screen to warn when ``` is used without a language.

tag (label) pull requests

The API seems to support tagging pull requests, but it's not surfaced in the UI.

As a maintainer of a few repos that get a ton of pull requests, it would be incredibly helpful to be able to tag pull requests to sort and select them based on arbitrary overlapping semantics, such as the area of the program that they touch, whether they are a bugfix or new feature, whether we're awaiting the user signing a CLA, etc.

Milestones and assignment are great as well, however, they do not address quite the same use cases. Milestones are for organizing release trains (and super helpful!), and assignment is for indicating that a user is responsible for a pull req (also super helpeful!), but this is more about arbitrary overlapping categories, which tags are perfect for.

Syntax highlighting when reviewing pull requests

Reviewing pull requests would be a little less painful if syntax highlighting was turned on.

Add ability to follow organizations like a user

I want to be able to see when a new repository is created in an organization that I follow, or when members are (publically) added to an organization, similar to the timeline view of new repos created by users I am following.

filter issues by whether they are a pull request

i'd prefer pull requests in the context of issues, specifically, being able to filter pull requests by label or milestone. after all, pull requests are a type of issue. i'm also interested in issues that are not pull requests.

personally, i never use the "filter pull requests by user", so i would prefer if the pull request tabs were merged into the issues tab, making the pull request tab a special subset of the issues tab, and have the "filter pull requests by user" field be toggle-able. Perhaps make labels toggle-able as well just for ubiquity.

Put number of pages next to Wiki in the menu

This way we know if there actually is any content there.

We've practically been trained to not bother clicking the Wiki menu item because of how often there's nothing there.

Bonus: Make it green when there are new pages since the last time I visited the repo's wiki.

When reviewing code, don't lose comments when escape or cancel is hit.

Oh it's so painful when writing a long detailed code review comment and then accidentally hitting escape and finding out it's gone forever. Cache that text and put a little "Draft" marker on the page when somebody closes the comment form by accident.

disable further commenting on an issue or pull request

Sometimes issue comments can devolve into a mess of trolls complaining after a repository maintainer has decided against an issue, it would be helpful if a repository could disable new comments on an issue.

The reopen case can be handled by cross linking in a new issue.

Explicit "mark as merged" option in pull request UI

Pull requests are automatically marked as merged when the commits are not modified before pulling them into the main branch.

However, for repos that receive a lot of pull requests, the option is to either (a) have an excessive number of merge commits, or (b) force pull requestors to continually rebase on the lastest upstream, or (c) rebase/cherry-pick/am the patches on my repo, and forego the "merged" data point.

In many cases, (a) is unacceptable. Merge commits are used for specific cases, and "fixed a typo in a doc" is not worthy of the added noise.

If you are merging, let's say, 10 pull requests in a single day, then (b) is also unacceptable. I can tell all 10 people to pull, rebase, and force-push, however: 1) this is very tedious, as I have to wait for users to do this, and often explain how, etc. and 2) it creates a race condition if all 10 people do this, because they will have to do it again after I've merged one of their commits.

So, we fall back on (c) and, due to the impossibility of automatically determining whether a pull request was merged, it looks like Node doesn't accept patches.

It'd be great if I could explicitly indicate in the UI that a pull request was merged, so that the data could be more accurate.

Hierarchical repository ownership for organizations

At my company, we have a number of open-source projects on github, and they are spread out in various user and organization accounts. We are considering consolidating under one big github organization, but that has a big problem: when we do that, the organization will have one flat, monolithic repository list and it will be hard for the public (and us) to navigate it. And individual groups within our company won’t get recognition for their own repositories.

It would be great if github could add the ability to have hierarchy in an organization’s repositories, without git itself having to be aware of that hierarchy. A possible alternative is to allow organizations to be members of other organizations, and display the hierarchy of repositories below each organization on that org’s github page.

This would be a big help for large organizations like ours.

add new issue label in issues dropdown on issue page

When I want to tag an issue with a label, sometimes that label doesn't exist yet. It's annoying to have to go to a separate page to create the new label, because that breaks the flow.

It would be great if it worked like the label drop-down in gmail. You start typing into a text box, and that filters by all the labels, but also has a link at the bottom to create a new label by that name.

emails for issues closed via commits should contain sha

If an issue is closed by a commit, the email notification generated should include in the message body what closed the issue, not merely who.

Change the target branch of a pull request

It can be necessary to pick a different target branch for a pull request if you accidentally select the wrong one, or perhaps you're asked to rebase the branch against a development branch vs a stable branch.

remove @-notification limit

When you @-mention enough people in a given comment, only the first ten @-mentions are linked to the user's profile and generate a notification. This limit should be removed.

This is supposedly for spam prevention, but it's more harmful than helpful. It's trivially bypassed by commenting multiple times. Furthermore, the limit is present even on private repositories, where only trusted users can comment anyway.

Add a consolidated feed from all Organisations

I want to see changes across 'organisation' contexts - siloing them by organisation means I miss interesting changes.

Use pushState instead of replaceState when changing tabs in a PR (aka "please don't break the back button")

Reproduce:

1. Open the pull requests page: https://github.com/joyent/node/pulls
2. Click on a pull request. Shows the "Discussion" tab.
3. Click the "Commits" tab. The url changes, and the page updates.
4. Click the "Back" button.

Expect: Return to the "Discussion" tab.
Actual: Returns to the https://github.com/joyent/node/pulls page

Add "My repositories" section in Notification Settings

I observe all watched repositories via RSS feed (too much stuff for email notifications).
To have that possible I needed to turn off both Email and Web in Watching section, but that means I'm not notified via Email about new issues in repositories I maintain and that's really bad.

It'll be great to see My repositories section in settings, so I can turn on Email notifications for new issues in repositories I maintain.

Use pushState instead of replaceState when changing tabs in a PR

If you go to /pulls then click on a pull request, you'll see its discussion tab. If you click on the files tab, then hit back in the browser, you'll be taken to /pulls again.

This is particularly annoying because the only way to get back to the discussion tab is by clicking on that tab, which is right at the top of the page. When you're reviewing a PR, you would often read top to bottom and then want to make a general comment upon it, which means you're as far away from that button as possible.

Add ability to sort and/or filter /pulls page based on target branch

In Node, we usually have two active branches: a stable branch (ie, v0.10) and an unstable branch (ie, master).

It'd be nice to be able to just show pulls that are targeting the stable branch, so that I could see if there's anything outstanding before doing a new release.

Pull Request web page has no link to the branch

Really needs:

• An obvious link back to the PR branch.

Would be nice:

• Git remote url

Would be even nicer:

• Command to copy to clipboard that pulls the PR branch without adding a new remote.

Disable edit-in-place for a repository (or specific files)

As a maintainer of a repository, I'd love to accept easy pull requests via website editing for documentation, since that is easy to verify just by looking at it.

However, code changes (especially C++ and JavaScript) frequently leads to syntax errors and broken tests, because it's very difficult to verify that code is correct just by looking at it in the editor.

I'd love to be able to disable the edit-in-place features for joyent/node. As a bonus, it'd be nice if I could enable it only for the doc/ folder of the repo, but disable it for the rest of the repository. But for us, disabling it on the src and lib folders would be worth disabling it for the entire repository if that's easier to do.

Convince github to create an official public place to post and discuss issues and feature requests for github.com (aka: Make this repo unnecessary)

Just what the title says.

I want to post issues for github.com on github.com, and discuss them with other github users, so that's why this repo exists. But it shouldn't exist. Github should take this over, and make it a thing.

This is valuable for all the same reasons why public issues forums on open source projects and other websites are valuable: it allows users to discuss and refine a use case that they're trying to get help with, allows us to help each other, and then when githubbers respond, it is clear that it's an issue that's being worked on and planned, so we don't feel ignored or neglected.

Of course, people often email [email protected] with issues about their credit cards, usernames, ssh keys, and other things that might contain private info. So it would take some care to help ensure that doesn't happen. Perhaps it would be worthwhile to add a feature to github issues that filters out likely private information, like anything matching /{[0-9]{4} ?){4}/ or whatnot could be replaced with XXXX XXXX XXXX XXXX.

Parallel diffs (side-by-side)

Would be nice to have the option to view diffs side-by-side as well as line-over-line.

private issues or pull requests for public repositories

In the course of maintaing a project it may be necessary to keep some information from the public while a security issue or other scenario is worked on.

Users or organizations that pay for private repositories should be able to create or mark an issue or pull request as private, from there only users specifically mentioned in the issue would have access.

Special care would need to be handled for issue cross linking and other notifications.

Issues <--> Discussions

A dedicated feature for discussions would be great. Issues has the connotation of being directly tied to your codebase (bugs, feature requests/changes, etc.)

My company, being that we are primarily a distributed team, use issues as more of a hodgepodge for everything and it can be quite cumbersome. I know there are tools for this; basecamp, sprint.ly, etc. but having everything under one roof is ideal.

Currently we separate things by milestones and/or labels, but having separation of actual issues and discussions would be spectacular.

Show number of forks that actually have changes

Lot of projects have a large number of forks with no changes on them. It would be great to have the number next to the fork button show the number of forks with changes.

Gist OAuth scope is too permissive

Currently when an app requests permission to create gists, they also get permission to list all private gists, and thus view and edit them. This means my gists are no longer private. @will has a detailed explanation of the problem: https://gist.github.com/will/4198815

Sidebar gets squashed after visiting issues

This is for new respository design.

Steps to reproduce (on this repository for example):

1. On this page (or any other issue/PR page)
2. Click "github" (the repository name in the top left).
3. This is what I get (attention to sidebar):
   

Note: Happens from time to time, not always.

re-add `/repo` as a shortcut to a repo in search

I loved this search feature:

/repo

Esp in the cases where I couldn't remember who was the author or a project or the author was known but it was a lot of characters to type.

However, with the recent search updates, it seems the only way to get that functionality is:

username/repo

Inline issue search from new issue title field

It's quite common to get a lot of duplicate issues in rapid succession. (Especially if, for example, the npm registry goes down for a minute, and 10 people all come and report it around the same time.)

Also, sometimes an issue is not really new, and people are just lazy to search, or don't realize that they can, so you get a lot of duplicates.

It'd be nice if, as you started typing in the issue title, it could search for existing issues that seem similar, and then give the user the option to go and see if their issue is the same as that other one. Of course, it wouldn't be perfect, and the UI might be tricky to get right, but it'd be a really nice way to help save time for the issue reporter and the project maintainer.

Links within wiki pages get rewritten incorrectly

Example at https://github.com/kriskowal/q/wiki/API-Reference. We have Markdown that says

[`promise.inspect`](#promiseinspect)

but GitHub rewrites that to

https://github.com/kriskowal/q/wiki/API-Reference#wiki-promiseinspect

which is a broken link.

New github design doesn't show last touched author of a file.

Here is the old design:

Compared to the new one:

The new design doesn't include the last modified by information. It used to be a quick way to review which contributor is affecting which files, but now we only get the commit message and its time.

When editing an issue or comment the preview button is MIA.

Why make us guess that our GitHub Flavored Markdown is 100% correct when going back and editing a typo?

Label HTML/CSS projects as such even when they use Compass

Some of my small HTML/CSS experiments are labelled as Ruby as they contain the Compass config file (config.rb). This skews my stats and has let some of the aggregators to suggest that I am proficient in Ruby, possibly to the detriment of my future employers.

Follow Semver rules when sorting tags

When you go to the Tags page for any repo using semver:

Today:

• 1.0.0-1
• 1.0.0

It should be:

• 1.0.0
• 1.0.0-1 The - means pre-release or release candidate, it is older than 1.0.0.

Fix JS showing up as Perl

This happens on pretty much every JS project I make and I'm not sure why.

Example: https://github.com/wearefractal/fixnode

GH thinks this is 91% perl even though the project is just JSON, JS, a LICENSE, a README, and a gitignore

Ability to sort stars by most starred count

The dropdown on the stars page lets you sort by recently and last updated, but not the most important metric to me which is the star count.

Maybe first starred to be the inverse of recently added maybe as well would be nice?

Disable green merge button for a specific repository

On joyent/node and isaacs/npm, we have a strict rule about not merging pull requests using the green "merge" button, because it creates excessive merge commits. (See additional discussion in #2.)

But the button is large, and inviting. It'd be nice to conditionally disable it per repository.

Make /pull on a repo redirect to /pulls

Pull requests have a /pull/:id schema. For other places, removing a fragment leads to the parent view, for example /issues/:id works fine - remove the ":id" part leads to /issues. For pull requests this doesn't work.

Having a redirect from /pull to /pulls would fix this without breaking anything. The correct implementation probably would've been a /pulls/:id schema.

Add explicit `+1` feature for issues that isn't a comment

Often people post github issue comments like 👍 just so that they can get notified when there are updates, and to indicate that they are also interested in an issue.

It'd be nice if they could just click a thing to do that, without posting a comment that emails everyone else uselessly. It could even put the 👍 comment on the page for cute factor if you feel that's important, but without emailing everyone.

For bonus points, let the project maintainers sort the issues list by the number of votes.

Then the 👍 behavior would be useful, rather than spammy.

---

Update: (there's a Change.org petition for this now](https://www.change.org/p/github-inc-add-voting-functionality-for-github-issues)

Three clicks to submit pull req??

When I open up a fork of a repo, like isaacs/node or something, I want to be able to submit a pull request with one click from any branch I've pushed to recently.

This was a pretty awesome feature that was added a while ago, and I've gotten quite used to it.

However, in the new repo view, now it's 3 clicks, which is kind of crazy. I click "Pull requests" on the right, and that shows me pull requests into my fork, which I never want. Then I click "New pull request" button, and instead of creating a pull request, it shows me a compare view. THEN, finally, I can click "Create pull request from this compare view".

Kind of a weird user flow.

I see that there's a tiny almost-too-faint-to-see grey label on isaacs/node that says "This branch is 0 commits ahead and 0 commits behind master". Well, that's kind of obvious, because I'm looking at my own master branch. Then off to the right (but not all the way to the right), there's the "pull request" link.

But even that is a) pretty hard to notice, and b) not showing the "new pull request" link for my recently pushed branches.

This is arguably GitHub's most important user flow: Fork, push, pull request. Please don't add obstacles to it!

Issues list: Show all issues that *lack* a tag/milestone/assignee

It'd be nice to be able to view all the issues that don't have an assignee, label, or milestone, so that a project maintainer can more easily triage new issues, without having to sift through those that have already been categorized.

Project language color bar is distracting and weird

The new design puts a rather brightly colored bar on across the top of the repo. This bar tells me the language of the project I'm looking at.

By the time I'm looking at a project, I already know the language that it's written in. That's probably why I'm there. If I'm not sure, it takes basically zero effort to find out anyway.

This information is not nearly important enough to justify the very pretty, but very distracting bar at the top of the main repo page.

In general, doing things that make github less pretty, but more useful, will always be appreciated. Every pixel that changes without increasing utility is only an increase in noise, even if it looks "cleaner" or "nicer". GitHub is not a site that I visit so that I can fawn over the lovely web2.0 design. I judge UI changes by how they impact my workflow. I literally never need to be told the language that a project uses, and it's screaming this on every page.

Sort tags chronologically on the tags page

Tags are currently sorted by the tag name, but that sorting isn't always correct because it's not a semver-compliant sort.

Instead sort the page by date. The newest tag will always be at the top, and it will be semver-sorted most of the time.

This idea is from a comment made by @isaacs on #33.