Blog: Managing the Deluge of Atom Issues


This is the discussion topic for the Atom blog post: Managing the Deluge of Atom Issues.


I get a “404 file not found” when I click your link.


Sorry, fixed now. (I had to create the topic here before I could publish the post … chicken and egg thing.)


You should look into embedding Discourse for comments :slight_smile:

Really enjoyed your writeup, and I think it’s spot on. Separating issues from discussions gives a GitHub repo much better focus. We (the Discourse team) love seeing setting a good example for this workflow.

p.s. you might wanna check out the WIP Feature Voting plugin. We’ll be dogfooding it on Meta soon, and after that there’s a good chance we’ll bundle it for all our Business customers.


I’m familiar with the system. I’m not sure that we want to have comments for all blog posts right now. We’ll see how this experiment goes :grinning:

Thanks! I’m glad to hear that it makes sense to other open-source maintainers!


Yes, that’s a good write up.
I was always annoyed to see issues used for asking questions…
Now, on some projects, there is just no other way to reach the maintainer…
At least, Atom has Discourse, which is good for questions. And asking before opening an issue…

One thing annoys me in Discourse, though: the mix between Atom topics and Electron topics. It would have been cleaner to separate them in two distinct boards. I suppose it is too late now…


There’s another kind of issue that actually in state of deluge, and of wich I want to raise awareness of: Pull Request.

Especially pull request on core packages. Basically packages bundled with atom receive a lot less attention than the core itself. However they are still responsible for a lot of the behavior an atom user will see when interacting with the software.

Because of this, and because core packages are way easier to develop/understand than atom/atom there’s a lot of pull request on them. Initial triage is quite snappy (and I want to applaud Wliu for somehow being everywhere at the same time)

However once a pull request has been marked as “need-review” that seems to happens anytime between the next day and the end of time. There’s a lot of bundled package with PR almost a year old. Some form of dialog, or even a no + a reason, would be better than the current situation.

The Quality Initiative addressed some of those issues, but even that one is almost one year old now.

I think that’s one place among other where a voting system can help compensate deficiency in the current time allocation process.


I’ll be addressing PRs in a separate push. There are a lot of PRs in the queue, you’re correct. And they haven’t been handled well, I agree. The solution here isn’t to institute a voting system, it is to reduce the distance between needs-review and merged. Most PRs still require a lot of work and back-and-forth when they are marked as needs-review. If we can figure out how to help people create PRs that don’t require this back-and-forth, they will be merged faster and we’ll get more throughput.


In collaboration with one of the developers in our community we just released a tool that lets you easily migrate issues from GitHub to Discourse: