Encourage users to post discussion questions here instead of in GitHub Issues?


I’ve noticed that there are waaaay too many open GitHub issues for Atom (800 at the time of writing), and many of them seem to me to be or to have been issues that are more suited for discussion rather than bug reports or straightforward feature / enhancement requests (e.g. most things in more-information-needed that aren’t submitted directly from Atom stack traces, needs-reproduction, #5463, #5454, #5418, etc).

To help streamline the issue tracker, I feel like it might be a good idea if we as a community, when commenting on some of these GitHub issues, referred people to Discuss instead. This would encourage people to join the community here and keep the issue tracker for tracking bugs and feature requests.

What do you think @leedohm?


Just remember … you asked me what I thought :wink:

It’s funny you should mention this, because I’ve been hearing variations on this theme over the past few days from an episode of the Accidental Tech Podcast and an article on the Six Colors blog. The theme being that the community or the audience for a thing isn’t a monolithic structure but a Venn diagram:

If you tried to plot an audience you’d get a crazy set of overlapping and non-overlapping circles. Your Audience is the sum of many different audiences, all with different habits …

— Jason Snell, Six Colors Blog

Besides just the GitHub Issues pages and the Discuss forum, there’s also Twitter, an Atom IRC channel and even an Atom subreddit. Some people will be most comfortable communicating on one of those and less comfortable or actively dislike some of the others. And they’re all part of “the Atom Community”.

Given that context, I think someone could submit a PR to add something about Discuss to the CONTRIBUTING document. And I think that, if people are careful, it could be made clear that Discuss is an option for people in addition to the GitHub Issues of the various repos.

I just think that care is needed because there may be a delicate balance between “providing options” and “discouraging feedback”.


Yeah I completely agree. I didn’t want to inadvertently shut people down on GitHub Issues, but I do get the sense that a lot of people who post the kinds of questions I was talking about might not be aware of Discuss (let alone the other discussion channels for Atom), and might only be posting on GitHub because, well, they already have a GitHub account.

I do think though that having so many open issues is a problem for everyone (core team and community alike) – I’ve been sort of toying with the idea of an, for lack of a better term, “inbox zero-like” issue state for repos. Not that we should necessarily be aiming for 0 open issues (we can dream though :stuck_out_tongue_closed_eyes:), but rather that we should aim for an issue count that is easy to keep track of. Like, people familiar with the project should be able to keep a decently accurate mental model of what issues are still open at any given time. I don’t really know what that number would be (my guess from personal experience is that it would be no more than 100), but I know that 800 ain’t it.

For example, Atom gets so many duplicate issues, and there are so many open issues, that it be nearly impossible sometimes to find the original, unless it happens to be on the front page in GitHub Issues or someone happens to remember. If there were only 100 open issues, this wouldn’t be such a monumental task.

But then it is a tough balance, because like you alluded to, GitHub Issues is still the Atom community, not just an issue tracker, so it’s not clear how much we should be “regulating” it, even for these benefits. :confused:


It’s tough to just close issues that are “ideas”. Most of them are not that urgent, but still “nice to have”. So I guess that’s why the number keeps growing.

As an experiment for the ONE themes, I started adding stars to give issues some urgency or importance. https://github.com/atom/one-dark-syntax/issues?q=is%3Aissue+is%3Aclosed

:star: :star: :star: (Urgent. Some kind of bug or a must have feature)
:star: :star: (Less urgent, but should still be done)
:star: (Nice to have, but not critical)

Then you could easily sort to see the most important ones. Of course it could be a bit soul-crushing if you submit a new issue and it only gets one star. But might still be better than just being ignored. Then you know that somebody at least looked at it.