dear-github/dear-github

:incoming_envelope: An open letter to GitHub from the maintainers of open source projects

See Dear GitHub 2.0

---

---

Dear GitHub,

You have done so much to grow the open source community and make it really accessible to users. Somehow you have us chasing stars and filling up squares, improving the world’s software in the process.

However, many of us are frustrated. Those of us who run some of the most popular projects on GitHub feel completely ignored by you. We’ve gone through the only support channel that you have given us either to receive an empty response or even no response at all. We have no visibility into what has happened with our requests, or whether GitHub is working on them. Since our own work is usually done in the open and everyone has input into the process, it seems strange for us to be in the dark about one of our most important project dependencies.

The problems we most frequently have, and our best ideas for how to address them, are:

• Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.

• Issues often accumulate content-less “+1” comments which serve only to spam the maintainers and any others subscribed to the issue. These +1s serve a valuable function in letting maintainers know how widespread an issue is, but their drawbacks are too great. We’d like issues to gain a first-class voting system, and for content-less comments like “+1” or “:+1:” or “me too” to trigger a warning and instructions on how to use the voting mechanism.

• Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines, due to the inconspicuous nature of the “guidelines for contributing” link when creating an issue and the fact that it often contains a lot of information that isn’t relevant to opening issues (such as information about hacking on the project). Maintainers should be able to configure a file in the repo (interpreted as GFM) to be displayed at the top of the new issue / PR page instead of that link. Maintainers can choose to inline content there and / or link to other pages as appropriate.

Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!

Signed,

GitHub users

Are you the maintainer of a project on GitHub and want to sign as well? Please sign here

===

Dear Open Source Maintainers,

We hear you and we're sorry. We've been slow to respond to your letter and slow to respond to your frustrations.

We're working hard to fix this. Over the next few weeks we'll begin releasing a number of improvements to Issues, many of which will address the specific concerns raised in the letter. But we're not going to stop there. We'll continue to focus on Issues moving forward by adding new features, responding to feedback, and iterating on the core experience. We've also got a few surprises in store.

Issues haven't gotten much attention from GitHub these past few years and that was a mistake, but we've never stopped thinking about or caring about you and your communities. However, we know we haven't communicated that. So in addition to improving Issues, we're also going to kick off a few initiatives that will help give you more insight into what's on our radar. We want to make sharing feedback with GitHub less of a black box experience and we want to hear your ideas and concerns regularly.

We'll be in touch next week. Sorry it's taken so long, and thank you for everything.

—GitHub

dear-github's Issues

serialized test CI + merges

http://homu.io/ layers this quite nicely on top, but enabling something like this by default would prevent so many headaches. Especially with large projects, long running tests, with many contributors.

Better diffs for indent changes.

Currently, one of the hardest diffs to review, is when a bunch of code gets indented positively or negatively. It's hard to tell if the user actually made a change somewhere in the indent code because it all mostly looks the same.

Here is prime example: https://gist.github.com/blainekasten/cfd44975df7c294c54e6/revisions

Hardly any code was changed, just de-indented.

It would help if we could see the actual code that changed, and then indent changes were hidden and noted. Something that looked more like this:

- removedThisFunction(function() {
+  de-indented containing content 2 spaces
- });

API documentation

Would actually love to have a nice, well made internal Api documentation maker. Yes of course, the wiki is great, and you can actually do those things easily. But when working on a huge code base, the wiki does not really scale well and everything becomes quickly a giant pill of mess (imho).

There's tool like https://github.com/tripit/slate, but it is actually cool to have all in one place, centralized within Github.

Am I the only one? :)

Cross-repository milestones/versions

It would be very useful to have organization-wide milestones. I'm the lead developer an OS, and we use GitHub for development and version planning. What we really need is organization-wide milestones where we can add issues or milestones from any project in the organization.

Why are people not using another tool for features that are missing on github ?

So why are people not using another tool for features that are missing on github ?

This is just a simple question, I'm sure I've been missing something.

Public place to see people who have signed

For a group that is complaining about openness it felt weird filling out a form to "sign" this

Issue types at creation rather than labels later on

I think it would be much more beneficial for the library owners or maintainers if users can assign a label (category) of the issue created as a bug, enhancement, a feature request and so on at creation time so the maintainer can filter that and he can change that category at any point if the reporter mis-categorised it

Link to isaacs/github

https://github.com/isaacs/github/issues is a list of 442 open issues which are community sourced issues and suggestions and feature requests for Github itself. It'd be really nice to link to these as further examples of places Github could benefit from user feedback as well as user open source contribution.

GithHub's Code of Conduct

While this letter is very nice in many ways it fails to regard one of the biggest issues with GitHub which is their Code of Conduct, or as some like to call them Code of Conflict. This Code of Conflict brings issues to the ecosystem that never existed in the first place and is outright sexist and racist towards many groups.

GitHub's blogpost about the Code of Conflict
The Code of Conflict itself

Add a option to search in commits

I still don't get why such a seemingly simple thing as searching through a repository's commits is not implemented into GitHub. I mean, you can search for almost everything in GitHub, except for commits. I've found myself needing this multiple times already, but failing to find a solution within GitHub.

Add duplicate issue search when reporting new issues

https://youtu.be/YYTtPjvA9xk?t=43s

GetSatisfaction and StackOverflow REQUIRE you to search for issues BEFORE you're even allowed to post, because it uses what you're currently typing in as the body or subject of a new issue as search keywords. If you fail to locate any matching queries, you can then click a call to action which converts your search query into the starting basis of your new issue (so you don't have to retype it in).

I've been toying around with the idea of making an open-source hosted project on like heroku where you just oauth with the service and it adds a bot that suggests 3 related issues any time a new issue is created by a non-contributor to the repo (or something like that).

Allow downloading only a directory

ATM you cannot download a single directory in a repository. Sometimes the rep is too big, but you only need a small part.

This will make things better!

Was there any response?

I mean, we can describe a lot of issues and make a lot of proposals, but did someone from Github actually see this? Was there any reaction?

gh API should allow me to select the organizations to which a service gets access

If you allow a service (like a cloud CI service, a code review service etc. etc.) to access your account, it automatically gets access to all the organizations you are a admin of. That is too broad. It should be possible to decide to which organizations a third party gets access.

Access speed in China

China's software engineers are also using GitHub, but the network connection speed is always haunt us,

+1

lol...sorry, had to do it

Add support for inline vector images in Issues discussions. 99% of design sketches are made in SVG

Add support for inline vector images in Issues discussions.
99% of design sketches are made in SVG. Discussions are about design changes or proposed features, so a very common way is to sketch them with Inkscape. Yet in github markdown there is only support for display bitmap images. This forces us to convert any 3kb svg in a 200kb png.
It is inconvenient for us to upload them, and it is inconvenient for Github to store them.
Also bitmaps are not used anymore in high resolution devices. Many mobile app developers now use vector graphics because it scales easily and fit any devices resolutions, ratio, dpi, etc with no loss of quality. Not to mention the new web trends. Google popular "Material Design" is entirely made in SVG.
Developers need more often to post vector resources, icons, controls, components, and elements of design in vector format as inline images. Guthub should add support for vector images in the markdown syntax used in both the issues discussions and wiki.

GitHub Folders

I would love to be able to organize my repositories within folders. Right now, when someone views my list of repositories, there is a mix of client side and server side and various technologies. With folders, I could arrange my repos into a client/ folder and server/ folder.

A better example might be a project like ExpressJS. For illustration purposes, assume I wrote it and maintain the repositories for it.

mschwartz/Express/
mschwartz/Express/core - the core ExpressJS
mschwartz/Express/gzip - add gzip layer to ExpressJS
mschwartz/Express/ssl - add https layer to ExpressJS

Or if I want to fork someone else's repositories to create pull requests:

mschwartz/PR/
mschwartz/PR/some-repo
mschwartz/PR/some-other-repo

Backward URL compatibility needs to be considered. Perhaps mschwartz must have every folder leaf repository have a unique name. Thus:

mschwartz/Express/core
and
mschwartz/Foo/core

would be invalid. Only one "core" allowed.

The alternative to folders is organizations, which are way too heavyweight for many uses. An organization for Express as described above is fine, but for PR it seems like an ugly solution.

Disable reply by email

I'm sure some people like to be able to respond to an issue discussion by email, but personally I would like to be able to disable that feature for my repos.

1. Parsing emails is hard and there is always some left over.
2. People try to attach files on the email. Those files never reach the issues section.
3. Some people have holiday auto responses.

Consider sticking to the original signers and using Google Forms for extra signatures

Compare to https://extensiblewebmanifesto.org/. As we are already seeing merge conflicts abound, people aren't following the single-project-per-person format, and aren't alphabetizing.

Change Organization name proposal?

I propose to change the name of the organization from "dear-github" to "dear-company" or something more generic like that.

It would be nice if other repositories could be created within the organization such as "dear-apple", "dear-microsoft", "dear-google", etc.

This is just a thought, so no hard feelings if you don't want to deal with the complexities of doing so.

Bot infrastructure

Problem

Current GitHub API has endpoints that are suitable for most use cases but with protected branches new kind of functionality becomes reasonable: bots. Bots could be used to various things:

• reviews (like https://lgtm.co/ or http://homu.io)
• automatic merges (like http://homu.io)
• feature voting
• controlling infrastructure (like restarting CI jobs)

Workaround solutions

Creating new GH account (like @homu and @bors) and hook bot to all needed events in all needed repos.

Ideal solution

Allow user-like instances per repo/organization that would hold unique name and unique hook. Such instance would be allowed to comment, accept/reject PR, close issues. Giving commands to such would be via additional GFM sigil (like $) and would be restricted via additional permission level (like, reviewer).

Filter to search on other branches from a repo

At the moment if you search on a repository it's only going to search on master branch, in my opinion we need a filter to specify a different branch to search since sometimes master does not have the latest changes from a repo.

README text copy is well intentioned, but tone-deaf.

On one hand, signatories are asking Github to provide you a way to avoid +1 spam, a.k.a people trying to put their name on things to "add support" when they think their contribution is the reason it hasn't been done, but not really adding any productive resources to execute on it. The group is unhappy that Github has seemingly ignored your repeated requests for this feature.

On the other, Github has most likely heard these requests, if "[we've] told you them before". Who knows whether or not they don't have some well founded reason why they haven't implemented these improvements, or even that they agree but aren't able to allocate resources to them.

Instead, OP decided to create a form where people can put their name on things...to add support...in light of what the signatories feel have been ignored repeated requests for something.

This is arguably enough as far as steps to reproduce, however a recently approved PR now makes this so new signatories are asked to sign a separate Google Doc to avoid the technical/merge conflicts associated with new signatories. It's almost as if the project maintainers are ignoring requests for +1.

allow me to subscribe to certain aspects of a repo

I don't want notifications about everything that happens on some repos, but, for instance, only receive a notification, when there is a new release. This should be configurable on a per repo basis.

Link to isaacs/github issue repository

https://github.com/isaacs/github has much more Github wishlist issues tracked (449 of them as I write this, compared with this repository's 28).

I think the readme here should link there, and encourage in people (with CONTRIBUTING.md) to post issues there instead, so we'd have them in one place and not scattered about.

Handle dependencies between PRs

Often during development of a feature a number of smaller improvements/fixes/etc are discovered, which can yield their own PRs. But now the PR for the feature depends on a bunch of other PRs, and github handles this situation... poorly. Alternatives such as gerrit simply mark that one patchset is dependent on another one, and a merge of a dependent patchset is deferred (or not allowed) until the dependency is merged. Commits from the dependency are supressed in the display of the PR.

This is a common working style for many folks; it would be nice if github properly supported it.

Open-source apps alternative suggestions to this problem

This issue is for showing the solutions that the community might have to address this problem right now.

I felt the need for a system to improve the open-source contribution workflow while a go. I didn't thought about change Github itself, which is a great idea, instead what I did was start to build an app to solve this. I want to share my app here which is still under development but with the right help it might get somewhere. If others have similar a idea, please share.

My app is called RateIssues and the goal is:

An application interely open-source, build to help people start to develop and contribute with open-source code and improve the workflow of core contributors. Using a different UI and a better UX than the one provided by Github. Using the Github API.

Tell us concisely what other people changed in their forks

It's useful to be able to track the contributions made by people in their forks, even before they send a pull request. However, the 'Network' in 'Graphs' is hard to navigate. It would be nice to get the lists of commits that were not pushed, per branch.

Forks don't need to duplicate all branches by default

After I fork of a repo that has 50 branches, I find myself deleting all the copies of branches in my fork. I don't really need them often, as I just wanted to patch the fork's master. It would be nice to provide a setting and/or change the default on this.

Suggestion# Allow everyone/anyone to label issues that have been already submitted

Currently, GitHub provides a simple issue reporting interface through which reporters can submit just the issue information. This could help reduce mis-classification (incorrect labeling) of issues, for example, many reporting users may not know which category their issue belongs to at the time they are creating the issue. After the issues have been submitted, maintainers (only) can add the labels. This while capable of achieving better classification quality, puts the burden of labeling on maintainers. This can result in many issues staying un-labelled (e.g. Cabot et al (2015) found that only about 3% of GitHub projects have labeled issues).

A suggestion is to open up the labeling (of only submitted issues) to everyone. Labeling can evolve by the side of a submitted issue. So user/reporter A initially submits an issue without any label. This can avoid chances of mis-classification/incorrect labeling by user A at the time of creation of the issue. After some time, Maintainer B may come and add a label L1 to the submitted issue. User A may later decide to come back (for example, while checking back on his/her submitted issue) add a label L2 (this could be a wrong one). Later users/developers C, D and E who may become interested in the submitted issue may read it and add lables L1, L1 and L3. Thus L1 begins to emerge as a good label for the submitted issue.

These labels should not be restricted by the few basic ones (enhancement, bug, task etc.) instead anyone should be able to add any label that they have in mind (idea inspired from following works: Parsons and Wand, 2014; Lukaneyeko et al, 2014). This could potentially help tackle incorrect labeling. For example, in the above scenario, if label L2 is wrong (say enhancement for what is actually a bug), other labels L1 (say error), L3 (say fix) could potentially indicate to the maintainer that its more about bug than enhancement. Thus maintainers/readers/contributors does no have to depend on a single label by a single reporter or a single maintainer and an issue has better quality classification.

This is what over time it should look like:

Issue Label

(Displays incorrect information) Enhancement(1), Bug (2), error (1), fix (1)

So one contributor has labelled enhancement, two contributors have labelled bug, one contributor has labelled error, one contributor has labelled fix and so on.

Link to @stubailo leads to @trek

Filter out issues that will be auto-closed by a PR

If an issue is due to be closed by a PR, but isn't closed yet it would be good to filter them out some how.

Suggestion: Introduce a Discussion tab

Problem with issues is to be forced to close them

• As a maintainer, you are forced to take a binary decision, where in practice, the reality is a lot less black and white.
• The wording is very strong, your issue has been closed which provokes a very negative reaction from the person on the other side. It makes dealing with issues a confrontation instead of a collaboration.
• Many issues we receive are not issues but questions, suggestions, thanks, reminders...

Solution: introduce a discussion tab

• Engineering wise, it would be very simple: the same backend as issues but without a badged count. (If you really insist, could badge for unread discussions).
• Many projects are moving discussions outside of github, for example for React we redirect people to Discourse. We'd rather stay on github since many discussions happen there anyway.
• It would reduce a lot of presure from maintainers as they are not forced to make a decision for all those discussions. The community can help each other out.

Structured Voting

Up-down voting is an ancient concept. Switch to Emoji Reactions (ala Stack) instead.

Add a button to sync a fork with its parent

At the moment, you can either use the command line or use an ugly hack with a pull-request.

The first method will end up with even branches, while the second will end up with 1 commit ahead of the parent repository.

A third (more drastic) solution is described by a commenter here and it's basically "throw away the entire repo and fork it again every time you want to contribute".

GitHub's Permission System is Flawed

This is an open letter to @github on behalf of third-party app developers.

For a very long time, permission scopes has been a common issue for both users and app developers.
These scopes are extremely permissive and far too broad, preventing users from using third-party applications.

We need a more granular permission system and we hope you listen to this.

Below you can find some examples that describes exactly what we mean by how flawed the system is and some suggestions to improve it.

---

gist scope

Grants write access to gists.

Let's say you want to build an app like GistBox to organize gists. In order to read read private gists you would need to request the gist scope.

Here's what users would see:

Even if you don't want to create any gists, you still need to request write access. Some users may find that ok, but other users can be afraid of having someone creating or editing their precious code snippets.

Solution: what if we had read_public:gist, read_private:gist, write_public:gist, and write_private:gist instead?

---

public_repo scope

Grants read/write access to code, commit statuses, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories.

Another example: let's say you want to create an app like Waffle, HuBoard, or ZenHub to manage your issues. In order to have a basic functionality like creating issues on public repositories, you would need to request the public_repo scope.

Here's what users would see:

Note how broad this permission is. These apps have no interest on wikis, deploy keys, webhooks, or anything like that. But still, that's the only way to go.

Solution: what if we had read_public:repo_code, read_public:repo_issues, and write_public:repo_stars instead?

---

repo scope

Grants read/write access to code, commit statuses, collaborators, and deployment statuses for public and private repositories and organizations.

Finally, the issue I'm personally facing right now. Let's say you want to build an app like DevSpace to read public and private events. For this we'd have to use the repo scope.

Here's what users would see:

This is probably the most shocking permission scope. Even though we don't want to write anything we'd still need to request a permission that can change code, issues, and many other important things from private repos.

Solution: what if we had read_public:events_repo, read_private:events_repo, read_public:events_org, and read_private:events_org instead?

---

You see, those are just few examples, there are many other apps facing the same issue:

• https://github.com/ZenHubIO/support/issues/77
• https://github.com/waffleio/waffle.io/issues/1957
• huboard/huboard#203
• huboard/huboard#468
• astralapp/astral#1
• astralapp/astral#11
• mozilla/science.mozilla.org#11
• jollygoodcode/jollygoodcode.github.io#6
• houndci/hound#925
• bkeepers/github-notifications#146
• holman/ama#635
• isaacs/github#268
• isaacs/github#311
• isaacs/github#31
• https://twitter.com/iandees/status/692855774645604359
• https://twitter.com/jasontrill/status/690813850350854144
• https://twitter.com/omarqureshi/status/655148749019303936
• https://twitter.com/YAMPST/status/623204972029734914
• https://twitter.com/codingjester/status/613019497549705217
• http://blog.waffle.io/updated-permissions/
• https://gitter.zendesk.com/hc/en-us/articles/200176672-Authenticating-with-GitHub
• https://blog.outlearn.com/shortcomings-of-github-oauth-for-multiple-scope-permission-levels-d4e959d2c6fe

---

@syropian, @ashumz, @acroca, @drusellers, @burtonjc, @pierrebeugnot, @rauhryan, @homeyer, @sxgao3001, @marydavis, @nparsons08, @zhangchiqing, @wbeard, @jamie, @diophore, @glenngillen, @troy, @winston do you agree?

---

I love GitHub and I hope this discussion contributes back to their product. There's a lot of potential on this community and I believe we can make a change.

Tag starred repositories in order to filter them easily afterward

Finding a specific starred repo among hundreds of others is kind of hard today. It could be quite useful to be able to tag a repository once starred, for instance adding graph databases or frontend tools. In other words, a kind of quick search using your own labels. Thus, we'd be able to order and group them using those tags in the /stars section.

GitLab

Over and over again today people have brought up GitLab. It seems like a good product but I do not have any experience with it.

I want to open a thread for people to discuss:

• Positives of GitLab
• Negatives of GitLab (If there are problems I want them out in the open)
• Are projects willing to move from GitHub to GitLab?

If it is a truly superior product I would consider moving all of my projects over there and I'd talk to the Babel team about moving everything there.

If anyone has migrated a project from GitHub to GitLab, could they detail what is kept/lost in the transfer? Does it keep issues/PRs/etc?

Watch only for release tags

Let me watch a repository, but notify me about releases made.

And GitHub does not send email to me when somebody opened an issue in my repo.

Instead of using a configuration file for the issue tracker "header", perhaps we should just have a configurable field.

I don't want junk files in my source control that have no significance outside of GitHub. Let's keep that kinda of stuff on GitHub. We don't set privacy settings in the repo files. We shouldn't have to do so for this either.

Suggestion: Visible status/acceptance/voting for pullrequests in overview (with example)

Problem

As reviewer:

• With a lot of Pullrequests it's hard to know what has been reviewed by whom

As submitter:

• It is hard to keep overview which of my work has enough 👍 by the right people to move on

Our workaround solution:

+1

Our process requests that you wait for 2 people giving you +1

status

• Ready for review
• work in progress
• please feedback WIP

Feedback requested by

We also @ the people we "need" feedback from (usually people who worked on related code)

Atm we have implemented this via labels - but given that labels are also used in issues it's a bit suboptimal and overwhelming (too many labels) - also it feels basic workflow like this (status, feedback, etc) should be part of the product

Ideal solution:

See in the overview which pull requests have which status and been approved by whom (only project-related people should be able to vote)

Option to show all closed/opened issues relating to a release/tag

To manually create something as detailed as the Bootstrap releases is not very fun.

https://github.com/twbs/bootstrap/releases

Submodule commit diff should have a link to the diff in submodule repo

When a reference to a submodule changes, the commit page only displays the old and new sha1s 👎 . It would help a lot to have a link to the corresponding diff in the submodule's repo.

Add feature to disable pull requests on a repository

Like disabling Wiki and Issues in the project's Settings view I would like to be able to disable pull requests on a repository.

This will be very useful for projects which have only a mirror on GitHub and they DON'T want to use GitHub's pull request mechanism for accepting contributions.
Or a project open sourced by a company is in the process of accepting GitHub pull requests but not yet, they still have some work to do internally before they are ready. (e.g. Google's TensorFlow project used to not accept pull requests through GitHub at the very beginning, but now they do)

Mirror examples:

• Linux kernel - 92 people wasted their time sending pull requests because they haven't read how to contribute to the Linux kernel guide
• Qt project - GitHub is only used as a mirror and not accepting contributions through it, they use their own Gerrit instance
• kdeconnect-kde - GitHub is only used as a mirror and not accepting contributions through it
• kdeconnect-android - GitHub is only used as a mirror and not accepting contributions through it

And many others... the maintainer(s) of the project have to tell people every time that submitting pull requests through GitHub is NOT the way to contribute to the project, and to keep telling them to read the contributing guidelines and close their pull request:

• qt/qtbase#6

Having the option to disable pull requests on a project would solve this problem.

Remove spammers / moderation

For example 506 and 507, we don't want that kind of submissions.

Add issue templates

Nearly every issue tracker (JIRA, Google Code, Flyspray, Bugzilla, etc.) can do this, so its lack of availability in Github is puzzling.

Allowing us to prefill issues asking for certain information would ensure more meaningful bug reports, and reduce the amount of time we have to spend asking bug reporters for basic information (software version, platform, steps to reproduce, etc.).

Setting to make it require your approval to be added to repository.

@sindresorhus just tweeted a web.archive.org link to this which brings up a good point.

We should be able to set whether or not people can auto add us to repositories as collaborators or if when they do, it requests us to approve it.

How about asking for powerful issue tracking APIs instead of feature development?

Disclaimer: I don't work for Github.

Github is a business, and they support for free a huge lot of Open Source initiatives. I believe a huge portion of the influential developers that signed the open letter, are employed by large companies, and even if not, they probably can appreciate that supporting Open Source is not the main business of Github. That said, do you all think the features you are requesting benefit the majority of Github projects?

I would say proposing API hooks that allow the Open Source community to implement all of your proposed features would be not only viable, but also would provide more flexibility. For instance:

• APIs that allow for validation of issue created: Github would receive the POST request, would proxy to your web hook and would present your Github Markdown response, or in case of the proper response code, just allow the issue creation.
• Replace the "New Issue" button action by redirecting to a URL (that could potentially be hosted on Github Pages) and provide a POST route for this page for submission. Developers could than create forms and validate as they wish, and also use the validation hook proposed above to make sure data is correct after all.
• To allow for 👍 issues, an validation / extension to comments on issues could be provided. For instance, after validating the comment, the hook could respond with a payload to disable notification for this particular comment.

I will not go further in hypothetical APIs, my point is: We can all understand how Github works internally or have a good guess. In my personal opinion one of the strengths of Github is being a small company (at least in development team size) and we would all be very sad if Github becomes a large corporation with internal issues. Requesting that much attention would cause them to consider hiring more developers, or making the product more feature packed and that's not necessarily beneficial for small projects, for private paid accounts and etc.

Github excels in being simple. All of you inferential Open Source masters could probably figure this out better than I can, but I would like to propose we advocate for better advanced APIs instead of advanced of feature packed interfaces. No one wants Github issue tracker to compete with Jira, right?