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 “
👍” 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!
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.