Facing Deluge of Issues with Atom Code Editor, GitHub Tries New Triage

After introducing an updated version of the popular Atom code editor -- and facing a deluge of more than 4,000 open issues -- GitHub is changing the way it handles bug reports, feature requests and other feedback.

GitHub, perhaps known more for hosting open source code repositories than building code editors, last week released Atom 1.7 and a beta of the next version, 1.8. The new stable version includes improvements in: tab management; working with files in the Tree View; adding project folders via the command line; crash recovery; and many more areas, including several enhancements to the Windows experience.

However, as the code editor has hit new levels of popularity -- recently reaching 1 million active users -- there has apparently been a corresponding increase in bug reports, feature requests and other issues, prompting a change in direction in handling those.

"As of this writing, the Atom organization has well over 4,000 open Issues across over 190 repositories," said GitHub staffer Lee Dohm in a blog post Tuesday titled Managing the Deluge of Atom Issues.

The Atom team relies on volunteers to help triage issues, answer questions and so on, but apparently is having a hard time keeping up with triage -- examining a new issue to see what needs to be done and applying a label to help the team discover and categorize issues.

The Atom Code Editor
[Click on image for larger view.] The Atom Code Editor (source: David Ramel)

"As the Atom community grows, managing feedback becomes an ever-increasing percentage of the time we have to maintain things," Dohm said. "Because of this, we want to try some new strategies to:

  • Get people the help they need as fast as possible.
  • Focus the maintainers’ attention on the things that need fixing.
  • Focus on the things that can be fixed now.

For reported issues that aren't really issues -- rather discussion topics or questions -- the Atom team has set up Discuss, the official Atom and Electron message board. The Help menu in the new 1.7 version now features a Community Discussion item, along with Report Issues and Search Issues items.

"The general rule of thumb is that GitHub Issues is best for things that have a definition of 'done': they can be fixed, added, resolved, have a stake driven through its heart or otherwise laid to rest," Dohm said. "For things where there isn’t a clear goal or end state, where you want to debate theory, or ask questions, Discuss and the Atom Slack are the way to go."

For "issues" that have no way of being fixed, the team will ask the issue reporter to clarify what needs to be done to resolve it. If that remains unclear or unachievable, the issue will be closed.

To address issues that get stuck in limbo -- if a maintainer's request for more information is ignored, for example -- a new "more-information-needed" label will be used. If a one-week reminder is also ignored, the issue will be closed after 30 days.

"To be clear, the goal of this effort is not to bring Atom down to zero open Issues," Dohm said. "There will always be things that we want to work on or bugs we need to fix. The goal here is to be better stewards by being more responsive, to be more transparent by telling you what we need in order to complete things, and to make Atom’s Issues lists easier to navigate by keeping them clean."

The new Discuss site has categories for: support, Electron (formerly called Atom Shell, upon which the Atom code editor is based); packages; features; themes; FAQ; meta; and uncategorized.

The top non-support posts deal with topics such as a dockable framework based on Electron; using Atom for academic writing; Visual Studio Code and Atom and so on.

In the support category, the top issue over the past year is "Atom keeps freezing—how can I find out which package is causing this?" Other issues deal with 64-bit Atom on Windows, CSSLint configuration, slowness in opening files and many more. The issue with the most all-time replies (145) and views (about 64,500) is "Why is Atom so slow?"

That issue was presented in the context of a comparison with Brackets.

"Let's try and keep the topic constructive rather than just venting frustrations," Dohm replied to one post under that issue in August 2014.

About the Author

David Ramel is an editor and writer for Converge360.