A zealous cadre of open source project maintainers is hoping to inspire change at GitHub by publicizing their complaints regarding issue management. After pursuing official channels without receiving a response, the group’s members say that they are frustrated by a lack of communication:
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.
Authors of the “Dear GitHub” repository, which has no public members, collectively penned an earnest letter that outlines three critical problems they perceive with the way issues currently work.
The first problem the group states is a lack of features for GitHub issues, and they propose a simple solution:
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.
The group is also calling for GitHub to create a “first-class voting system” that would declutter the ubiquitous “+1″‘s that litter nearly every popular project’s issues queue. They recognize the +1s as important feedback but demand a better UI to organize this information:
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.
The third issue directly impacts the open source workflow, which becomes inefficient when issues and requests are improperly submitted. The proposed solution streamlines important information that guides users toward submitting meaningful contributions:
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.
Authors of the letter have waited years for progress on these issues. The 600+ project maintainers who have signed the document are incapable of making these changes themselves, since GitHub’s infrastructure is not open source.
GitHub’s Paying Customers Don’t Share the Same Problems as Open Source Project Maintainers
With more than 12 million people collaborating across 31 million repositories as of January 2015, GitHub is home to the largest collection of code on the planet. Its emphasis on “social coding” and free hosting for public projects has made GitHub the defacto place to make code available for collaboration. As a result, many free users often forget that it’s the GitHub Enterprise customers who keep the lights on at the company.
Julian Dunn, a product manager at Chef, wrote a response to the “Dear GitHub” letter. He contends that GitHub, unless forced by heated press coverage, isn’t likely to address these concerns.
“If I were the product manager for GitHub, the answer to your requests would probably be ‘no,’” Dunn said. “That’s not because I think your feature requests aren’t legitimate. It’s because they don’t impact paying customers very highly. And as a company whose developers have to eat, GitHub is probably going to prioritize those customers first.”
His reasoning is that the issue management problems that plague open source communities don’t affect GitHub’s bread and butter to the same degree.
“Paying customers use private repositories and/or GitHub Enterprise, and the wild[er]-west aspects of an open-source ecosystem simply don’t exist inside a company,” Dunn said. “You’re unlikely to see +1-DDoS-type behavior inside private repos, for example.”
GitHub has yet to officially address the “Dear GitHub” letter. With a growing list of more than 600 maintainers of popular open source projects signing the document, it will soon be in the company’s best interest to communicate a response. Authors of the letter are hoping the company will choose to act in support of its open source community to solve the unique challenges that project maintainers contend with when hosting on GitHub.
If you’re an open source project maintainer, is this a letter you would sign? Does the current way that GitHub issues are structured satisfy the needs of your project and its users? Would the proposed solutions make a difference for your project?
We do maintain a few dozen private repositories on GitHub and have discussed “GitHub Issues” with other paying customers as well.
Some teams do use GitHub issues as it’s easy to connect to PRs, link to specific lines of a certain commit and generally relate to the context of ongoing development. This also reduces the management time from copying over tasks to another PM system and switching between views all the time, or lacking certain features that GitHub provides.
We have considered using GitHub issues actively for the development department and I can totally agree that more powerful GitHub issues with better categorization, custom fields, a bit more flexible views/reports and “Due Date” would help immensely for technical teams using private repos as well.